Menu
▾
▴
springframework-developer — Spring Framework developers list
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: <jue...@we...> - 2004-09-04 11:08:58
|
Ideally, WebLogic should work properly with standard JTA =
TransactionManager resume in all cases, not needing the proprietary =
forceResume call. However, the least we can expect is that forceResume =
works properly: You could send a corresponding bug report to BEA, for =
WebLogic 7.0. However, they might tell you that they fixed the issue in =
WebLogic 8.1...
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Fr 03.09.2004 23:31
An: spr...@li...
Betreff: Re: [Springframework-developer] WLS 7 and TX suspend/resume - =
continue.
As I already wrote in my JIRA comments: Many thanks for your efforts, =
Dmitri!
I assume that with JtaTransactionManager, you'll get an =
IllegalStateException ("cannot resume rollback-only transaction" or the =
like), and with WebLogicJtaTransactionManager, you'll get the NPE in =
WebLogic code?
This really seems to be a bug in WebLogic 7.0... At least it should work =
properly as long as not suspending a transaction that has been marked as =
rollback-only.
Juergen
________________________________
Von: spr...@li... im Auftrag =
von Dmitri Maximovich
Gesendet: Fr 03.09.2004 23:07
An: spr...@li...
Betreff: [Springframework-developer] WLS 7 and TX suspend/resume - =
continue.
I just tried WLS 7 with Spring 1.1rc2 and BMT transaction demaraction. =
It
doesn't work with standard JtaTransactionManager or with
WeblogicJtaTransactionManager, so something fundamentally broken in WLS7 =
(same
NPE as described in JIRA SPR-251).
Next I'll try to use WLS TransactionManager (exposed in JNDI) to =
suspend/resume
transaction without Spring to see it it's going to work.
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <jue...@we...> - 2004-09-04 10:46:04
|
Everybody, =20 I plan to release 1.1 final tomorrow, right before I leave for London = and Rome for 10 days. IMO it's already overdue, so I'm very keen on = sticking to that deadline. =20 If you've got some remaining time today, feel free to polish, complete = docs, write further unit tests, test the samples. However, please do no = further commits tomorrow, as I'm gonna take the release snapshot = tomorrow morning. =20 BTW, you might have noticed that I recently did some minor deprecations: = A couple of "getNrOfXxx" methods have been renamed to "getXxxCount", for = consistent naming throughout the framework. =20 I've also deprecated ThreadLocalTargetSourceStats' "getInvocations", = "getHits", "getObjects" to "getInvocationCount", "getHitCount", = "getObjectCount", respectively. (I hope you don't mind that, Rod.) =20 Let there be 1.1 final! :-) =20 Juergen |
|
From: <jue...@we...> - 2004-09-03 21:40:31
|
As I already wrote in my JIRA comments: Many thanks for your efforts, =
Dmitri!
=20
I assume that with JtaTransactionManager, you'll get an =
IllegalStateException ("cannot resume rollback-only transaction" or the =
like), and with WebLogicJtaTransactionManager, you'll get the NPE in =
WebLogic code?
=20
This really seems to be a bug in WebLogic 7.0... At least it should work =
properly as long as not suspending a transaction that has been marked as =
rollback-only.
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Dmitri Maximovich
Gesendet: Fr 03.09.2004 23:07
An: spr...@li...
Betreff: [Springframework-developer] WLS 7 and TX suspend/resume - =
continue.
I just tried WLS 7 with Spring 1.1rc2 and BMT transaction demaraction. =
It
doesn't work with standard JtaTransactionManager or with
WeblogicJtaTransactionManager, so something fundamentally broken in WLS7 =
(same
NPE as described in JIRA SPR-251).
Next I'll try to use WLS TransactionManager (exposed in JNDI) to =
suspend/resume
transaction without Spring to see it it's going to work.
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Dmitri M. <ma...@md...> - 2004-09-03 21:21:58
|
I just tried WLS 7 with Spring 1.1rc2 and BMT transaction demaraction. It doesn't work with standard JtaTransactionManager or with WeblogicJtaTransactionManager, so something fundamentally broken in WLS7 (same NPE as described in JIRA SPR-251). Next I'll try to use WLS TransactionManager (exposed in JNDI) to suspend/resume transaction without Spring to see it it's going to work. |
|
From: Colin S. <col...@ex...> - 2004-09-03 21:03:56
|
There is a kernel upgrade scheduled on the host, which requires a reboot. |
|
From: Rod J. <ro...@in...> - 2004-09-03 20:06:39
|
Thanks. I've tended to implement my own in a subclass, but Spring should provide it... -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of j=FCrgen h=F6ller [werk3AT] Sent: 02 September 2004 22:23 To: spr...@li... Subject: Re: [Springframework-developer] flush() method on = HibernateTemplate OK, convinced. I've just added a "flush" method to HibernateOperations/HibernateTemplate and JdoOperations/JdoTemplate, = with the latter delegating to the existing JdoDialect.flush method. =20 Juergen =20 _ |
|
From: <tho...@tr...> - 2004-09-03 16:32:08
|
All, I have implemented the support for a custom type being returned from a stored procedure. This forum entry provides more detail: http://forum.springframework.org/viewtopic.php?p=2396#2396 I have tested this with a live Oracle database and I will add some unit tests over the weekend. The changes to existing code are minimal and it is 100% backwards compatible. Thomas |
|
From: Nick L. <nl...@es...> - 2004-09-02 23:24:03
|
> > > > I would like to use the Spring taglibs with the portlet > framework, and I've > > done some work to try and get this happening. My impression > from the design > > discussion referenced above is that this is the direction > it was heading in. > > Yes, we would like to see full Spring View technology support for the > Portlet API and this includes the taglibs. Did you make > PortletApplicationContext a subclass of WebApplicationContext? > Yes. If I ever get it to the point where I'm happy with it and it works I'll send in some patches. > > > > Is this the best approach? As a general strategy am I > better off altering > > the portlet framework to do things like making a default > ThemeResolver > > available etc, or should I be looking at modifying the > taglibs to work > > without that stuff? > > ThemeResolver is missing since it is expected that the Portal will > handle these things. Perhaps the bridge View Servlet could provide a > mock implementation to satisify the tablibs? > After thinking about it some I came to the same conclusion - I haven't had time to try it yet, though. |
|
From: <al...@jt...> - 2004-09-02 22:30:48
|
<html><head>
<style>
.white { color:#FFFFFF }.index { background-color:#FFFFFF }.index-passed { =
color:#004400 }.index-failed { color:#FF0000; font-weight:bold }.index-head=
er { font-weight:bold }.link { font-family:arial,helvetica,sans-serif; font=
-size:10pt; color:#FFFFFF; text-decoration:none; }.tab-table { margin: 0em =
0em 0.5em 0em; }.tabs { font-family:arial,helvetica,sans-serif; font-size:8=
pt; color:#000000; font-weight:bold; padding: 0em 2em; background-color:#EE=
EEEE; }.tabs-link { color:#000000; text-decoration:none; }.tabs-link:visite=
d { color:#000000; text-decoration:none; }.tabs-selected { font-family:aria=
l,helvetica,sans-serif; font-size:8pt; color:#000000; font-weight:bold; pad=
ding: 0em 2em; }.tabs-selected { border: inset; }.header-title { font-famil=
y:arial,helvetica,sans-serif; font-size:12pt; color:#000000; font-weight:bo=
ld; }.header-label { font-weight:bold; }.header-data { font-family:arial,he=
lvetica,sans-serif; font-size:10pt; color:#000000; }.modifications-data { f=
ont-family:arial,helvetica,sans-serif; font-size:8pt; color:#000000; }.modi=
fications-sectionheader { background-color:#000066; font-family:arial,helve=
tica,sans-serif; font-size:10pt; color:#FFFFFF; }.modifications-oddrow { ba=
ckground-color:#CCCCCC }.modifications-evenrow { background-color:#FFFFCC }=
.changelists-oddrow { background-color:#CCCCCC }.changelists-evenrow { back=
ground-color:#FFFFCC }.changelists-file-spacer { background-color:#FFFFFF }=
.changelists-file-evenrow { background-color:#EEEEEE }.changelists-file-odd=
row { background-color:#FFFFEE }.changelists-file-header { background-color=
:#666666; font-family:arial,helvetica,sans-serif; font-size:8pt; color:#FFF=
FFF; }.compile-data { font-family:arial,helvetica,sans-serif; font-size:8pt=
; color:#000000; }.compile-error-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#FF0000; }.compile-warn-data { font-family:arial,=
helvetica,sans-serif; font-size:8pt; color:#CC9900; }.compile-sectionheader=
{ background-color:#000066; font-family:arial,helvetica,sans-serif; font-s=
ize:10pt; color:#FFFFFF; }.distributables-data { font-family:arial,helvetic=
a,sans-serif; font-size:8pt; color:#000000; }.distributables-sectionheader =
{ background-color:#000066; font-family:arial,helvetica,sans-serif; font-si=
ze:10pt; color:#FFFFFF; }.distributables-oddrow { background-color:#CCCCCC =
}.unittests-sectionheader { background-color:#000066; font-family:arial,hel=
vetica,sans-serif; font-size:10pt; color:#FFFFFF; }.unittests-oddrow { back=
ground-color:#CCCCCC }.unittests-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#000000; }.unittests-error { font-family:arial,he=
lvetica,sans-serif; font-size:8pt; color:#FF0000; }.checkstyle-oddrow { bac=
kground-color:#CCCCCC }.checkstyle-data { font-family:arial,helvetica,sans-=
serif; font-size:8pt; color:#000000; }.checkstyle-sectionheader { backgroun=
d-color:#000066; font-family:arial,helvetica,sans-serif; font-size:10pt; co=
lor:#FFFFFF; }
</style>
</head><body>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"header-title">BUILD COMPLETE - =
build.93</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build: </span>09/03/2004 00:16:17</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>13 minutes 25 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed: </span>09/02/2004 14:41:17</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try: </span>fix copy/paste error on param name. code was still correct=
though</td></tr></table><p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"/><p>
<p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"><tr><td class=
=3D"compile-sectionheader"> Errors/Warnings: (=
6) </td></tr><tr><td><pre class=3D"compile-error-data">N=
ote: Some input files use or override a deprecated API.<br class=3D"none"/>=
Note: Recompile with -deprecation for details.Note: /jteam/build/checkout/s=
pring/spring/mock/org/springframework/mock/web/MockHttpSession.java uses or=
overrides a deprecated API.<br class=3D"none"/>Note: Recompile with -depre=
cation for details.<br class=3D"none"/>Note: Some input files use or overri=
de a deprecated API.<br class=3D"none"/>Note: Recompile with -deprecation f=
or details.<br class=3D"none"/></pre></td></tr></table><p>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"unittests-sectionheader"> =
Unit Tests: (1470) </td></tr><tr><td><tabl=
e width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"c=
enter"><tr><td class=3D"unittests-data"> failure =
</td><td width=3D"40%" class=3D"unittests-data">testHomePage</td><td width=
=3D"40%" class=3D"unittests-data">org.springframework.apptests.buildtest.Al=
lTests</td></tr></table></td></tr><tr></tr><tr><td colspan=3D"2"> </td=
></tr><tr><td colspan=3D"4" class=3D"unittests-sectionheader"> =
Unit Test Error Details: (1) </td></tr><tr=
><td class=3D"unittests-data" colspan=3D"2"> Test: test=
HomePage</td></tr><tr><td class=3D"unittests-data" colspan=3D"2"> =
Class: org.springframework.apptests.buildtest.AllTests</td></tr>=
<tr><td class=3D"unittests-data" colspan=3D"2"> Type: junit.=
framework.AssertionFailedError</td></tr><tr><td class=3D"unittests-data" co=
lspan=3D"2"> Message: Exception while testing URL http://loc=
alhost:13084/buildtest:java.io.IOException</td></tr><tr><td class=3D"unitte=
sts-error" colspan=3D"2"><pre>junit.framework.AssertionFailedError: Excepti=
on while testing URL http://localhost:13084/buildtest:java.io.IOException<b=
r>=09at org.springframework.apptests.buildtest.AllTests.testHomePage(Unknow=
n Source)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Meth=
od)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess=
orImpl.java:39)<br>=09at sun.reflect.DelegatingMethodAccessorImpl.invoke(De=
legatingMethodAccessorImpl.java:25)<br></pre></td></tr><tr><td colspan=3D"2=
"> </td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"modifications-sectionheader"> =
Modifications since last build: =
(3) </td></tr><tr class=3D"modifications-evenrow"><td c=
lass=3D"modifications-data">modified</td><td class=3D"modifications-data">c=
olins</td><td class=3D"modifications-data">src/org/springframework/transact=
ion/interceptor/TransactionProxyFactoryBean.java</td><td class=3D"modificat=
ions-data">fix copy/paste error on param name. code was still correct thoug=
h</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-da=
ta">modified</td><td class=3D"modifications-data">jhoeller</td><td class=3D=
"modifications-data">test/org/springframework/beans/CustomEditorTestSuite.j=
ava</td><td class=3D"modifications-data">StringTrimmerEditor implements "ge=
tAsText" to return an empty String for a null value in case of "emptyAsNull=
"</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-d=
ata">modified</td><td class=3D"modifications-data">jhoeller</td><td class=
=3D"modifications-data">src/org/springframework/beans/propertyeditors/Strin=
gTrimmerEditor.java</td><td class=3D"modifications-data">StringTrimmerEdito=
r implements "getAsText" to return an empty String for a null value in case=
of "emptyAsNull"</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"distributables-sectionheader"> =
Deployments by this build: (8) </td><=
/tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/checko=
ut/spring/spring/dist/spring.jar</td></tr><tr class=3D"distributables-oddro=
w"><td class=3D"distributables-data">Building war: /jteam/build/checkout/sp=
ring/spring/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr><td c=
lass=3D"distributables-data">Building war: /jteam/build/checkout/spring/spr=
ing/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr class=3D"dist=
ributables-oddrow"><td class=3D"distributables-data">Building war: /jteam/b=
uild/checkout/spring/spring/autobuilds/apps/buildtest/dist/buildtest.war</t=
d></tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/che=
ckout/spring/spring/autobuilds/apps/jpetstore/war/WEB-INF/lib/jpetstore.jar=
</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distributables-d=
ata">Building war: /jteam/build/checkout/spring/spring/autobuilds/apps/jpet=
store/dist/jpetstore.war</td></tr><tr><td class=3D"distributables-data">Bui=
lding jar: /jteam/build/checkout/spring/spring/autobuilds/apps/jpetstore/wa=
r/WEB-INF/lib/jpetstore.jar</td></tr><tr class=3D"distributables-oddrow"><t=
d class=3D"distributables-data">Building war: /jteam/build/checkout/spring/=
spring/autobuilds/apps/jpetstore/dist/jpetstore.war</td></tr></table>
</body></html> |
|
From: <jue...@we...> - 2004-09-02 21:19:41
|
OK, convinced. I've just added a "flush" method to = HibernateOperations/HibernateTemplate and JdoOperations/JdoTemplate, = with the latter delegating to the existing JdoDialect.flush method. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: Do 02.09.2004 21:17 An: spr...@li... Betreff: Re: [Springframework-developer] flush() method on = HibernateTemplate Here it is again Juergen, Colin Sampaleanu wrote: > FLUSH_EAGER is not at all the same, in my opinion. When doing mixed > Hibernate based code (with JDBC or EJBs) I on a number of occasions > had to issue flushes to ensure something was safely available for the > other code, but it was certainly nothing I wanted even most of the > time (default FLUSH_EAGER)... And your typical DAO based on something > like HibernateDaoSupport doesn't usually have the concept of working > with multiple templates. > > I was originally kind of against the idea, especially given the fact > that in non Session bound to thread mode the operation would be > completely redundant. But at the end of the day, the template is used > by DAOs, DAOs are very aware of Hibernate specifics, and I think > there's nothing fundamentally that wrong with allowing an explicit > flush to be done in an easy fashion. I don't agree this operation is > really related to transaction state either. Whether that data is in > the Session cache or has gone out to the db, the transaction can > generally still commit or rollback with the same effect. And Hibernate > itself will on its own criteria also decide to flush the cache > sometimes, such as when you do a query. In the end, I think it's > somewhat contrived if some app has to do a half dozen > HibernateCallback cases where the only only operation inside them is a > flush() call. > > > j=FCrgen h=F6ller [werk3AT] wrote: > >> Well, that's what HibernateTemplate's FLUSH_EAGER mode is meant for: >> To automatically flush right after each operation, even if a prebound >> Session is used. I would generally recommend to use such a >> preconfigured HibernateTemplate instance here, no matter if a shared >> one like in a HibernateDaoSupport or a newly instantiated one for a >> given SessionFactory. >> >> I'm not keen on a flush operation on HibernateTemplate itself: That's >> not really a data access operation like the other methods there, but >> rather a method that just modifies the state of the transaction. If >> someone doesn't like the approach with a preconfigured >> HibernateTemplate, there's still the option of a custom >> HibernateCallback, even if just for a save and a flush. >> >> Juergen >> >> >> ________________________________ >> >> Von: spr...@li... im Auftrag >> von Colin Sampaleanu >> Gesendet: Mi 01.09.2004 17:34 >> An: spr...@li... >> Betreff: [Springframework-developer] flush() method on = HibernateTemplate >> >> >> >> Juergen, >> >> We had a request on the forums (and I've seen this before) to add >> flush() as a method on HibernateTemplate. Of course, this would be >> completely useless (or superfluous) in the case there is no existing >> thread bound session (or at least an existing outer transaction to = bind >> the new session to and keep it there afterwards). But most people do = use >> HibernateTemplate in their DAOs with the expectation that the Session = is >> already around or will be created and stay around, and it's probably >> reasonable to allow them to do a flush without having to use >> HibernateCallback, since they could have just done a one-off = operation >> like save() and then want to ensure that changes go out, for example >> when combining with JDBC based operations in a DAO. >> >> What do you think? > ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Olivier J. <oli...@pc...> - 2004-09-02 20:46:14
|
Greetings all,
while trying to bring spring into the developments of my company, I
faced the following issue which I think could lead to an improvement :
We have a command in a simpleForm with some custom type component at
top. Some of those objects contains a Map storing Date.
The point is that I'd like to use a custom DateEditor to format them
when rendering my view and when bind them to the command.
I made a custom DateEditor and I registered it. It works fine for
gettings String from the request and filling my command but when
rendering the view, as I use the spring taglib to bind on the map
containing the object with Date inside, the eventual custom
PropertyEditor is given called with the whole map and the result is
compulsory a String
(org.springframework.validation.BindException.getFieldValue).
What could be slightly more powerful is to allow to return Object, by
calling getValue instead of getAsText. In order to achieve ascendant
compatibility and have getAsText called by default, we could provide an
Interface (either empty or with the getValue method, both ways are
unperfect, I know) like ObjectReturningPropertyEditorInterface which
would enable the getFieldValue method to check whether the getAsText or
getValue method should be invoked.
This way I could code a PropertyEditor, implementing the new interface,
overriding the getValue by returning a copy of the map given in setValue
and altering the value by remplacing incoming Date bucklets with a
formatted result.
If this sounds ok, I would be honored to propose a patch against CVS
head even if it's not for including into 1.1 final.
I'm not sure I've been clear enough, my jsp code looks like this :
<spring:bind path="command.customer">
<%-- customer is an instance of a Customer which contains a collection
of Affectation --%>
<c:foreach items="${affectations}" var="affectation">
<%-- the Affectation class mainly contains a couple of Date that I
what to format --%>
<tr><td><INPUT type="text"
name="fake_map_for_catching_setting_of_begin_date[<c:out
value="${affectation.id}"/>]" <c:out value="${affectation.beginDate}"/> ....
</c:foreach>
</spring:bind>
I'd really be happy to provide my first patch to spring if my idea could
bring something interesting to the whole.
Greetings
Olivier Jolly
|
|
From: Colin S. <col...@ex...> - 2004-09-02 19:49:33
|
I'll add this to the wiki and/or the manual. I wonder which is more appropriate? As for CMT+Spring Tx, it also works in JBoss, albeit you can get spurious warnings about unknown connections or it closing connections for you (and in both cases the warnings seem to be spurious), under some circumsances... Colin jürgen höller [werk3AT] wrote: >Current summary of Spring/JTA compatibility: > > >Spring's JtaTransactionManager within EJB BMT or web components: > >* Everything but transaction suspension will work properly on any J2EE server, as it just touches the JTA UserTransaction, which is properly covered by standard J2EE. > >* Transaction suspension (REQUIRES_NEW, NOT_SUPPORTED) requires the JTA TransactionManager, which is not a public component of standard J2EE. However, it is a standard JTA interface, defined by the JTA spec, with somewhat well-defined semantics to rely on if - it is available. > >* Vendor-specific lookup of JTA TransactionManager is necessary, as J2EE does not define a standard location for it. By default, we autodetect whether the UserTransaction object implements the TransactionManager interface, which is the case of for a surprisingly large number of J2EE servers. > >* The BEA docs state that the JTA TransactionManager is officially supported for EJB BMT and web components, on both 7.0 and 8.1. It even explictly mentions that one reason to do this is transaction suspension. Official support for other vendors remains to be checked. > >* WebLogic needs "forceResume" to resume suspended transactions that have been marked rollback-only: This is provided by WebLogicJtaTransactionManager. Besides that special case, suspend/resume should work properly with Spring's standard JtaTransactionManager on WebLogic too (on both 8.1 and 7.0). > >* Suspend/resume via the JTA TransactionManager needs to be tested thoroughly on various J2EE servers: Currently known to work are Resin, JBoss, Orion/OC4J, JOnAS/JOTM, WebSphere 4.0, WebLogic 8.1 (with the above special treatment). To be tested: WebSphere 5.x, WebLogic 7.0. > > >Spring's JtaTransactionManager within EJB CMT: > >* Using direct JTA within EJB CMT is not covered by standard J2EE: Effectively, it is clearly forbidden by the EJB spec. This applies directly to Spring's JtaTransactionManager within EJB CMT, no matter if just touching the JTA UserTransaction or the JTA TransactionManager too. > >* Nevertheless known to work on WebLogic 8.1, including transaction suspension. Known to work on WebLogic 7.0 too, except for transaction suspension. Most important ones to test: WebSphere 4.0 and 5.x. Of course, this scenario remains outside of the J2EE spec: Explicit support needs to be checked for each vendor. > > >In total, the situation with direct JTA (no EJB CMT) is quite good: In such a scenario, most J2EE servers work properly with JtaTransactionManager's suspend/resume out-of-the-box (see above); I assume that WebSphere 5.x will work too. It seems that only WebLogic causes trouble here, and just in a special case... > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of jürgen höller [werk3AT] >Sent: Thursday, September 02, 2004 4:35 PM >To: spr...@li... >Subject: Re: [Springframework-developer] JTA transaction suspension on >WebSphere > > > > >>Isn user transaction object available trough bean context wrapper? >> >> > >Only for BMT, according to the EJB spec: > >"The getUserTransaction method returns the javax.transaction.UserTransaction >interface. The instance can use this interface to demarcate transactions and to obtain transaction status. Only instances of a session bean with bean-managed transaction demarcation can use this method." > >According to the spec, CMT beans are not supposed to touch direct JTA at all, not even the UserTransaction. While that still might work on some containers, you're outside the EJB spec here. And according to the BEA docs, WebLogic just officially supports the JTA TransactionManager for BMT too... > > > > >>>So I recommend to *either* work with EJB CMT *or* Spring-managed >>>transactions. Do not try to combine both unless you're aware that >>>you're violating the EJB spec. >>> >>> > > > >>Hey, that was my point! :-) >> >> > >OK, I admit I stole it, ehm, came to the same conclusion on my own ;-) However, it's important to explicitly state that using Spring-managed transactions with suspend/resume via the JTA TransactionManager *is* officially supported on WebLogic, for EJB BMT and web components. > > > > >>>However, EJB BMT with Spring-managed >>>transactions should work nicely, even if involving the JTA >>>TransactionManager on WebLogic. >>> >>> > > > >>I wonder if anyone tested it? >> >> > >I assume that it works with BMT on WebLogic 8.1, as it even works with CMT there. According to the BEA docs, it should work with BMT on WebLogic 7.0: This is explicitly stated there. They don't mention using JTA within EJB CMT, though, so I assume that combo is not officially supported. > > > > >>Anyway using BMT does not have much value, especially with MDB's and >>I believe it will also increase risks of losing data in case of >>container failures/crashes (XA transaction manger use heuristics in this >>case and should roll back everything correctly). >> >> > >Effectively, MDBs should be the only problem, as we can't do transactional message reception without CMT there. > >With BMT session beans or web components, Spring-managed transactions with JtaTransactionManager should be as powerful as CMT session beans, including transaction suspension and full recovery capabilities (which are provided by the JTA transaction manager, not by the EJB container). > > > > >>So, now it is unclear if it does work on WLS 8 in CMT scenario? >> >> > >Thomas just clarified that he indeed tested this on CMT, so it does work with CMT on WebLogic 8. That combo still outside of the EJB spec, though. > > >Juergen > > > > >>-----Original Message----- From: >>spr...@li... >>[mailto:spr...@li...]On >>Behalf Of Eugene Kuleshov Sent: Thursday, September 02, 2004 1:23 PM >>To: spr...@li... Cc: Dmitri >>Maximovich Subject: Re: [Springframework-developer] JTA transaction >>suspension on WebSphere >> >> >>Juergen, >> >>If I'm reading this correctly, JTA transaction manager interface in >>Weblogic available to beans that are managing transactions >>themselves, but not suppose to be used by beans under CMT. >> >>regards, Eugene >> >> >> >> >> >>>A further update: I've just discovered that WebLogic even >>>officially supports javax.transaction.TransactionManager as public >>>API! >>> >>>http://e-docs.bea.com/wls/docs70/jta/jtaapi.html >>> >>>"Client-initiated transactions-the JTA transaction manager >>>interface (javax.transaction.TransactionManager) is made available >>>to clients and bean providers through JNDI. This allows clients and >>>EJBs using bean-managed transactions to suspend and resume >>>transactions." >>> >>>They only interpret the semantics of resume a bit differently, i.e. >>>not automatically resuming a transaction that has been marked >>>rollback-only. They explicitly offer their proprietary forceResume >>>method for this. It's quite clearly a bug then that it doesn't work >>>in WebLogic 7.0: We could even try to report that to BEA! It does >>>work in WebLogic 8.1, though... >>> >>>So in principle, suspend/resume via the JTA TransactionManager *is* >>> supported by WebLogic, just with special semantics. And if you >>>need the forceResume semantics, you can use Spring's new >>>WebLogicJtaTransactionManager. Essentially, the JTA spec should be >>>clearer about the semantics of TransactionManager.resume here... >>> >>> >>> >> >> >>>________________________________ >>> >>>Von: spr...@li... im >>>Auftrag von jürgen höller [werk3AT] Gesendet: Mi 01.09.2004 22:01 >>>An: spr...@li... Betreff: Re: >>>[Springframework-developer] JTA transaction suspension on WebSphere >>> >>> >>> >>> >>>An update: The issue was indeed caused by Spring's transaction >>>synchronization in combination with EJB CMT transaction suspension. >>>Once you turn off Spring's transaction synchronization, which >>>causes our Hibernate support to fall back to direct JTA >>>synchronization, everything works nicely. I've also refined our >>>Hibernate LOB types to be able to work with direct JTA >>>synchronization too, so that our full Hibernate support works in >>>such a scenario without hassle. >>> >>>Furthermore, Victor was so kind to test a variety of combinations >>>with Spring-driven JTA transaction suspension on WebSphere, among >>>those with an outer transaction that has been marked rollback-only >>>(which doesn't work out-of-the-box on WebLogic). Fortunately, >>>everything worked nicely! >>> >>>Thus, it's now quite safe to assume that WebSphere's JTA >>>TransactionManager is fully compatible with Spring, at least on >>>WebSphere 4. It would be good to get some tests on WebSphere 5 - >>>any volunteers? This means, to the best of our current knowledge, >>>that we only need special handling (WebLogicJtaTransactionManager) >>>on WebLogic, and that the only container where suspend/resume >>>doesn't work in all cases is WebLogic 7. >>> >>>Juergen >>> >>> >>>________________________________ >>> >>>Von: spr...@li... im >>>Auftrag von jürgen höller [werk3AT] Gesendet: Di 31.08.2004 10:58 >>>An: spr...@li... Betreff: Re: >>>[Springframework-developer] JTA transaction suspension on WebSphere >>> >>> >>> >>> >>>Indeed, Thomas: I've pointed out exactly the same to Eugene on that >>> WebLogic issue in JIRA. >>> >>>FYI, I've just noticed that I might have misinterpreted Victor's >>>problem last night: He doesn't use Spring transactions with >>>REQUIRES_NEW, but rather an outer Spring transaction plus an inner >>>EJB CMT transaction with REQUIRES_NEW. Spring's >>>JtaTransactionManager never touches the JTA TransactionManager is >>>such a scenario, so it can't be caused by the suspend/resume >>>interaction there. >>> >>>I rather suspect that the problem is Spring's transaction >>>synchronization, which gets activated for the outer Spring >>>transaction, but doesn't get notified of the transaction suspension >>>caused by the inner EJB CMT transaction. Therefore, Spring's >>>Hibernate support within the inner transaction will still >>>synchronize with the outer Spring transaction, flushing the >>>Hibernate Session at completion of the *outer* rather than the >>>inner transaction. >>> >>>The solution I've suggested is to turn off Spring's transaction >>>synchronization in that case. It should always be turned off when >>>using transaction suspension driven by EJB CMT. See my JIRA >>>comments: >>> >>>http://opensource.atlassian.com/projects/spring/browse/SPR-295 >>> >>>As I've noted there, it would still be interesting whether >>>Spring-driven JTA transaction suspension works with WebSphere: >>>i.e., a Spring transaction demarcation with REQUIRES_NEW in case of >>>an existing transaction. We might still face problems there, of >>>course, but it seems to me that Victor's issue is not an indication >>>for those. >>> >>>Juergen >>> >>> >>>________________________________ >>> >>>Von: spr...@li... im >>>Auftrag von Thomas Risberg Gesendet: Di 31.08.2004 06:33 An: >>>spr...@li... Betreff: Re: >>>[Springframework-developer] JTA transaction suspension on WebSphere >>> >>> >>> >>> >>>This is not an issue for transactions declared with REQUIRED, >>>SUPPORTS, MANDATORY or NEVER. For these transactions there is no >>>need to mess with the JTA TransactionManager to suspend the current >>>transaction. UserTransaction is sufficient for these and this >>>should be portable between containers. >>> >>>The only trouble is with REQUIRES_NEW and NOT_SUPPORTED. Here we >>>have to bend the rules and use the JTA TransactionManager API if it >>>is available. This is where things break down since the appservers >>>don't seem to cooperate. Even WebLogic 8.1 did not work until we >>>used a WebLogic specific API call (forceResume). >>> >>>Thomas >>> >>> >>>Colin Sampaleanu wrote: >>> >>> >>> >>> >>> >>>>Eugene Kuleshov wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Colin Sampaleanu wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>'Eu' on his blog 3-4 days ago commented based on my own blog >>>>>>entry, and a forum message: >>>>>>http://jroller.com/page/eu/20040826#using_spring_jta_interfaces_from >>>>>> that section / C.2.4 /of the EJB spec says that the >>>>>>container, for EJBs, must implement the UserTransaction >>>>>>interface (and JTA 1.0.1) extension, but doesn't have to >>>>>>implement the other interfaces defined in the JTA >>>>>>specification. Fine, I've actually seen that before, >>>>>>coincidentally, when I was tracking something down a while >>>>>>ago, but I think a container is fundamentally broken if it >>>>>>_does_ expose the JTA TransactionManager interface, and it >>>>>>doesn't behave as per the spec. The spec for an API is the >>>>>>spec for the API. If you expose the interface at all, then >>>>>>you need to expose it correctly... That's essentially how I >>>>>>read that clause, and how I see things. In any case, I hope >>>>>>the situation is going to improve, certainly WLS 8 works >>>>>>where WLS 7 doesn't, with out WL specific adapter... >>>>>> >>>>>> >>>>> >>>>>Perhaps I wasn't clear enough. My point is that it is a bad >>>>>idea to mix usage of JTA interface with declarative container >>>>>managed transacttions for EJBs. In other words it is probably >>>>>to use Spring JTA helpers/wrappers in web layer which is not >>>>>using EJB's. >>>>> >>>>>Anyway it would be good have some more advanced tests to ensure >>>>>that JTA actually work in WLS8 (and other containers) in case >>>>>of failure/rollback with multiple XA resources involved into >>>>>transaction (especially resources from different vendors, such >>>>>as Oracle, Sybase, MQSeries). >>>>> >>>>> >>>>I fully agree about the tests. This is part of the reason I >>>>created the ejbtest integration sample. Hopefully we will keep >>>>adding to it. >>>> >>>>As for the clause in question, it says: >>>> >>>>"The EJB container must include the JTA 1.0.1 extension, and it >>>>must provide the javax.transaction.UserTransaction interface to >>>>enterprise beans with bean-managed transaction demarcation >>>>through the javax.ejb.EJBContext interface, and also in JNDI >>>>under the name java:comp/UserTransaction, in the cases required >>>>by the EJB specification. The other JTA interfaces are low-level >>>>transaction manager and resource manager integration interfaces, >>>>and are not intended for direct use by enterprise beans. >>>> >>>>This is unfortunately not worded very well in my opinion, in >>>>terms of being very clear about CMT. Consider that this is the >>>>section of the spec called 'The Container Provider's >>>>Responsibility'. It is about the minimum set of services which >>>>the container must provide to the EJB. I do not equate anything >>>>in the paragraphs above as saying (with any adequate level of >>>>clarity) that if the container chooses to expose other APIs the >>>>EJB _is not_ allowed to use them. I read the last sentence as a >>>>justification as to _why_ the container doesn't have to provide >>>>the other JTA interfaces. The spec is actually very specific >>>>about what EJBs may and may not do, consider threading for >>>>example. Again, my opinion is that if the container does choose >>>>to expose an API like JTA's TransactionManager, then it has to >>>>behave correctly, as an API is an API. >>>> >>>> >>>>Ultimately, only the spec writers know what they really intended, >>>>and I agree that people wanting to move an app from container to >>>>container, and from app server version to version, are not going >>>>to get as predictable results in a CMT+Spring Transaction setup >>>>as they would in a CMT alone, or Spring Tx alone setup. That >>>>said, it can still be a viable and useful combination. Over a >>>>period of some months, I migrated an app on JBoss from CMT EJB to >>>>no EJB with Spring Tx wrapping service beans, and the CMT+Spring >>>>Tx combo provided a valuable middle ground in the migration, in >>>>the perdio when there were still some EJBs, but a lot had already >>>> moved over. >>>> >>>>Regards, Colin >>>> >>>> |
|
From: Colin S. <col...@ex...> - 2004-09-02 19:18:35
|
Here it is again Juergen, Colin Sampaleanu wrote: > FLUSH_EAGER is not at all the same, in my opinion. When doing mixed > Hibernate based code (with JDBC or EJBs) I on a number of occasions > had to issue flushes to ensure something was safely available for the > other code, but it was certainly nothing I wanted even most of the > time (default FLUSH_EAGER)... And your typical DAO based on something > like HibernateDaoSupport doesn't usually have the concept of working > with multiple templates. > > I was originally kind of against the idea, especially given the fact > that in non Session bound to thread mode the operation would be > completely redundant. But at the end of the day, the template is used > by DAOs, DAOs are very aware of Hibernate specifics, and I think > there's nothing fundamentally that wrong with allowing an explicit > flush to be done in an easy fashion. I don't agree this operation is > really related to transaction state either. Whether that data is in > the Session cache or has gone out to the db, the transaction can > generally still commit or rollback with the same effect. And Hibernate > itself will on its own criteria also decide to flush the cache > sometimes, such as when you do a query. In the end, I think it's > somewhat contrived if some app has to do a half dozen > HibernateCallback cases where the only only operation inside them is a > flush() call. > > > jürgen höller [werk3AT] wrote: > >> Well, that's what HibernateTemplate's FLUSH_EAGER mode is meant for: >> To automatically flush right after each operation, even if a prebound >> Session is used. I would generally recommend to use such a >> preconfigured HibernateTemplate instance here, no matter if a shared >> one like in a HibernateDaoSupport or a newly instantiated one for a >> given SessionFactory. >> >> I'm not keen on a flush operation on HibernateTemplate itself: That's >> not really a data access operation like the other methods there, but >> rather a method that just modifies the state of the transaction. If >> someone doesn't like the approach with a preconfigured >> HibernateTemplate, there's still the option of a custom >> HibernateCallback, even if just for a save and a flush. >> >> Juergen >> >> >> ________________________________ >> >> Von: spr...@li... im Auftrag >> von Colin Sampaleanu >> Gesendet: Mi 01.09.2004 17:34 >> An: spr...@li... >> Betreff: [Springframework-developer] flush() method on HibernateTemplate >> >> >> >> Juergen, >> >> We had a request on the forums (and I've seen this before) to add >> flush() as a method on HibernateTemplate. Of course, this would be >> completely useless (or superfluous) in the case there is no existing >> thread bound session (or at least an existing outer transaction to bind >> the new session to and keep it there afterwards). But most people do use >> HibernateTemplate in their DAOs with the expectation that the Session is >> already around or will be created and stay around, and it's probably >> reasonable to allow them to do a flush without having to use >> HibernateCallback, since they could have just done a one-off operation >> like save() and then want to ensure that changes go out, for example >> when combining with JDBC based operations in a DAO. >> >> What do you think? > |
|
From: <jue...@we...> - 2004-09-02 19:01:15
|
Current summary of Spring/JTA compatibility: Spring's JtaTransactionManager within EJB BMT or web components: * Everything but transaction suspension will work properly on any J2EE = server, as it just touches the JTA UserTransaction, which is properly = covered by standard J2EE. * Transaction suspension (REQUIRES_NEW, NOT_SUPPORTED) requires the JTA = TransactionManager, which is not a public component of standard J2EE. = However, it is a standard JTA interface, defined by the JTA spec, with = somewhat well-defined semantics to rely on if - it is available. * Vendor-specific lookup of JTA TransactionManager is necessary, as J2EE = does not define a standard location for it. By default, we autodetect = whether the UserTransaction object implements the TransactionManager = interface, which is the case of for a surprisingly large number of J2EE = servers. * The BEA docs state that the JTA TransactionManager is officially = supported for EJB BMT and web components, on both 7.0 and 8.1. It even = explictly mentions that one reason to do this is transaction suspension. = Official support for other vendors remains to be checked. * WebLogic needs "forceResume" to resume suspended transactions that = have been marked rollback-only: This is provided by = WebLogicJtaTransactionManager. Besides that special case, suspend/resume = should work properly with Spring's standard JtaTransactionManager on = WebLogic too (on both 8.1 and 7.0). * Suspend/resume via the JTA TransactionManager needs to be tested = thoroughly on various J2EE servers: Currently known to work are Resin, = JBoss, Orion/OC4J, JOnAS/JOTM, WebSphere 4.0, WebLogic 8.1 (with the = above special treatment). To be tested: WebSphere 5.x, WebLogic 7.0. Spring's JtaTransactionManager within EJB CMT: * Using direct JTA within EJB CMT is not covered by standard J2EE: = Effectively, it is clearly forbidden by the EJB spec. This applies = directly to Spring's JtaTransactionManager within EJB CMT, no matter if = just touching the JTA UserTransaction or the JTA TransactionManager too. * Nevertheless known to work on WebLogic 8.1, including transaction = suspension. Known to work on WebLogic 7.0 too, except for transaction = suspension. Most important ones to test: WebSphere 4.0 and 5.x. Of = course, this scenario remains outside of the J2EE spec: Explicit support = needs to be checked for each vendor. In total, the situation with direct JTA (no EJB CMT) is quite good: In = such a scenario, most J2EE servers work properly with = JtaTransactionManager's suspend/resume out-of-the-box (see above); I = assume that WebSphere 5.x will work too. It seems that only WebLogic = causes trouble here, and just in a special case... Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: Thursday, September 02, 2004 4:35 PM To: spr...@li... Subject: Re: [Springframework-developer] JTA transaction suspension on WebSphere > Isn user transaction object available trough bean context wrapper? Only for BMT, according to the EJB spec: "The getUserTransaction method returns the = javax.transaction.UserTransaction interface. The instance can use this interface to demarcate transactions = and to obtain transaction status. Only instances of a session bean with = bean-managed transaction demarcation can use this method." According to the spec, CMT beans are not supposed to touch direct JTA at = all, not even the UserTransaction. While that still might work on some = containers, you're outside the EJB spec here. And according to the BEA = docs, WebLogic just officially supports the JTA TransactionManager for = BMT too... >> So I recommend to *either* work with EJB CMT *or* Spring-managed >> transactions. Do not try to combine both unless you're aware that >> you're violating the EJB spec.=20 > Hey, that was my point! :-) OK, I admit I stole it, ehm, came to the same conclusion on my own ;-) = However, it's important to explicitly state that using Spring-managed = transactions with suspend/resume via the JTA TransactionManager *is* = officially supported on WebLogic, for EJB BMT and web components. >> However, EJB BMT with Spring-managed >> transactions should work nicely, even if involving the JTA >> TransactionManager on WebLogic. > I wonder if anyone tested it? I assume that it works with BMT on WebLogic 8.1, as it even works with = CMT there. According to the BEA docs, it should work with BMT on = WebLogic 7.0: This is explicitly stated there. They don't mention using = JTA within EJB CMT, though, so I assume that combo is not officially = supported. > Anyway using BMT does not have much value, especially with MDB's and=20 > I believe it will also increase risks of losing data in case of=20 > container failures/crashes (XA transaction manger use heuristics in = this=20 > case and should roll back everything correctly). Effectively, MDBs should be the only problem, as we can't do = transactional message reception without CMT there. With BMT session beans or web components, Spring-managed transactions = with JtaTransactionManager should be as powerful as CMT session beans, = including transaction suspension and full recovery capabilities (which = are provided by the JTA transaction manager, not by the EJB container). > So, now it is unclear if it does work on WLS 8 in CMT scenario? Thomas just clarified that he indeed tested this on CMT, so it does work = with CMT on WebLogic 8. That combo still outside of the EJB spec, = though. Juergen > -----Original Message----- From: > spr...@li...=20 > [mailto:spr...@li...]On > Behalf Of Eugene Kuleshov Sent: Thursday, September 02, 2004 1:23 PM=20 > To: spr...@li... Cc: Dmitri > Maximovich Subject: Re: [Springframework-developer] JTA transaction > suspension on WebSphere >=20 >=20 > Juergen, >=20 > If I'm reading this correctly, JTA transaction manager interface in > Weblogic available to beans that are managing transactions > themselves, but not suppose to be used by beans under CMT. >=20 > regards, Eugene >=20 >=20 >=20 >> A further update: I've just discovered that WebLogic even >> officially supports javax.transaction.TransactionManager as public >> API! >>=20 >> http://e-docs.bea.com/wls/docs70/jta/jtaapi.html >>=20 >> "Client-initiated transactions-the JTA transaction manager >> interface (javax.transaction.TransactionManager) is made available >> to clients and bean providers through JNDI. This allows clients and >> EJBs using bean-managed transactions to suspend and resume >> transactions." >>=20 >> They only interpret the semantics of resume a bit differently, i.e. >> not automatically resuming a transaction that has been marked >> rollback-only. They explicitly offer their proprietary forceResume >> method for this. It's quite clearly a bug then that it doesn't work >> in WebLogic 7.0: We could even try to report that to BEA! It does >> work in WebLogic 8.1, though... >>=20 >> So in principle, suspend/resume via the JTA TransactionManager *is* >> supported by WebLogic, just with special semantics. And if you >> need the forceResume semantics, you can use Spring's new=20 >> WebLogicJtaTransactionManager. Essentially, the JTA spec should be >> clearer about the semantics of TransactionManager.resume here... >>=20 >=20 >=20 >>=20 >> ________________________________ >>=20 >> Von: spr...@li... im >> Auftrag von j=FCrgen h=F6ller [werk3AT] Gesendet: Mi 01.09.2004 22:01 >> An: spr...@li... Betreff: Re:=20 >> [Springframework-developer] JTA transaction suspension on WebSphere >>=20 >>=20 >>=20 >>=20 >> An update: The issue was indeed caused by Spring's transaction=20 >> synchronization in combination with EJB CMT transaction suspension. >> Once you turn off Spring's transaction synchronization, which >> causes our Hibernate support to fall back to direct JTA >> synchronization, everything works nicely. I've also refined our >> Hibernate LOB types to be able to work with direct JTA >> synchronization too, so that our full Hibernate support works in >> such a scenario without hassle. >>=20 >> Furthermore, Victor was so kind to test a variety of combinations >> with Spring-driven JTA transaction suspension on WebSphere, among >> those with an outer transaction that has been marked rollback-only >> (which doesn't work out-of-the-box on WebLogic). Fortunately, >> everything worked nicely! >>=20 >> Thus, it's now quite safe to assume that WebSphere's JTA >> TransactionManager is fully compatible with Spring, at least on >> WebSphere 4. It would be good to get some tests on WebSphere 5 - >> any volunteers? This means, to the best of our current knowledge, >> that we only need special handling (WebLogicJtaTransactionManager) >> on WebLogic, and that the only container where suspend/resume >> doesn't work in all cases is WebLogic 7. >>=20 >> Juergen >>=20 >>=20 >> ________________________________ >>=20 >> Von: spr...@li... im >> Auftrag von j=FCrgen h=F6ller [werk3AT] Gesendet: Di 31.08.2004 10:58 >> An: spr...@li... Betreff: Re:=20 >> [Springframework-developer] JTA transaction suspension on WebSphere >>=20 >>=20 >>=20 >>=20 >> Indeed, Thomas: I've pointed out exactly the same to Eugene on that >> WebLogic issue in JIRA. >>=20 >> FYI, I've just noticed that I might have misinterpreted Victor's >> problem last night: He doesn't use Spring transactions with >> REQUIRES_NEW, but rather an outer Spring transaction plus an inner >> EJB CMT transaction with REQUIRES_NEW. Spring's >> JtaTransactionManager never touches the JTA TransactionManager is >> such a scenario, so it can't be caused by the suspend/resume >> interaction there. >>=20 >> I rather suspect that the problem is Spring's transaction >> synchronization, which gets activated for the outer Spring >> transaction, but doesn't get notified of the transaction suspension >> caused by the inner EJB CMT transaction. Therefore, Spring's >> Hibernate support within the inner transaction will still >> synchronize with the outer Spring transaction, flushing the >> Hibernate Session at completion of the *outer* rather than the=20 >> inner transaction. >>=20 >> The solution I've suggested is to turn off Spring's transaction=20 >> synchronization in that case. It should always be turned off when >> using transaction suspension driven by EJB CMT. See my JIRA >> comments: >>=20 >> http://opensource.atlassian.com/projects/spring/browse/SPR-295 >>=20 >> As I've noted there, it would still be interesting whether >> Spring-driven JTA transaction suspension works with WebSphere: >> i.e., a Spring transaction demarcation with REQUIRES_NEW in case of >> an existing transaction. We might still face problems there, of >> course, but it seems to me that Victor's issue is not an indication >> for those. >>=20 >> Juergen >>=20 >>=20 >> ________________________________ >>=20 >> Von: spr...@li... im >> Auftrag von Thomas Risberg Gesendet: Di 31.08.2004 06:33 An:=20 >> spr...@li... Betreff: Re:=20 >> [Springframework-developer] JTA transaction suspension on WebSphere >>=20 >>=20 >>=20 >>=20 >> This is not an issue for transactions declared with REQUIRED, >> SUPPORTS, MANDATORY or NEVER. For these transactions there is no >> need to mess with the JTA TransactionManager to suspend the current >> transaction. UserTransaction is sufficient for these and this >> should be portable between containers. >>=20 >> The only trouble is with REQUIRES_NEW and NOT_SUPPORTED. Here we >> have to bend the rules and use the JTA TransactionManager API if it >> is available. This is where things break down since the appservers >> don't seem to cooperate. Even WebLogic 8.1 did not work until we >> used a WebLogic specific API call (forceResume). >>=20 >> Thomas >>=20 >>=20 >> Colin Sampaleanu wrote: >>=20 >>=20 >>=20 >>> Eugene Kuleshov wrote: >>>=20 >>>=20 >>>=20 >>>> Colin Sampaleanu wrote: >>>>=20 >>>>=20 >>>>=20 >>>>> 'Eu' on his blog 3-4 days ago commented based on my own blog >>>>> entry, and a forum message:=20 >>>>> = http://jroller.com/page/eu/20040826#using_spring_jta_interfaces_from >>>>> that section / C.2.4 /of the EJB spec says that the >>>>> container, for EJBs, must implement the UserTransaction >>>>> interface (and JTA 1.0.1) extension, but doesn't have to >>>>> implement the other interfaces defined in the JTA >>>>> specification. Fine, I've actually seen that before,=20 >>>>> coincidentally, when I was tracking something down a while >>>>> ago, but I think a container is fundamentally broken if it >>>>> _does_ expose the JTA TransactionManager interface, and it >>>>> doesn't behave as per the spec. The spec for an API is the >>>>> spec for the API. If you expose the interface at all, then >>>>> you need to expose it correctly... That's essentially how I >>>>> read that clause, and how I see things. In any case, I hope >>>>> the situation is going to improve, certainly WLS 8 works=20 >>>>> where WLS 7 doesn't, with out WL specific adapter... >>>>=20 >>>>=20 >>>>=20 >>>> Perhaps I wasn't clear enough. My point is that it is a bad >>>> idea to mix usage of JTA interface with declarative container >>>> managed transacttions for EJBs. In other words it is probably >>>> to use Spring JTA helpers/wrappers in web layer which is not >>>> using EJB's. >>>>=20 >>>> Anyway it would be good have some more advanced tests to ensure >>>> that JTA actually work in WLS8 (and other containers) in case >>>> of failure/rollback with multiple XA resources involved into >>>> transaction (especially resources from different vendors, such >>>> as Oracle, Sybase, MQSeries). >>>=20 >>>=20 >>> I fully agree about the tests. This is part of the reason I >>> created the ejbtest integration sample. Hopefully we will keep >>> adding to it. >>>=20 >>> As for the clause in question, it says: >>>=20 >>> "The EJB container must include the JTA 1.0.1 extension, and it >>> must provide the javax.transaction.UserTransaction interface to >>> enterprise beans with bean-managed transaction demarcation >>> through the javax.ejb.EJBContext interface, and also in JNDI >>> under the name java:comp/UserTransaction, in the cases required >>> by the EJB specification. The other JTA interfaces are low-level >>> transaction manager and resource manager integration interfaces, >>> and are not intended for direct use by enterprise beans. >>>=20 >>> This is unfortunately not worded very well in my opinion, in >>> terms of being very clear about CMT. Consider that this is the >>> section of the spec called 'The Container Provider's >>> Responsibility'. It is about the minimum set of services which >>> the container must provide to the EJB. I do not equate anything >>> in the paragraphs above as saying (with any adequate level of >>> clarity) that if the container chooses to expose other APIs the=20 >>> EJB _is not_ allowed to use them. I read the last sentence as a=20 >>> justification as to _why_ the container doesn't have to provide >>> the other JTA interfaces. The spec is actually very specific >>> about what EJBs may and may not do, consider threading for >>> example. Again, my opinion is that if the container does choose >>> to expose an API like JTA's TransactionManager, then it has to >>> behave correctly, as an API is an API. >>>=20 >>>=20 >>> Ultimately, only the spec writers know what they really intended, >>> and I agree that people wanting to move an app from container to >>> container, and from app server version to version, are not going >>> to get as predictable results in a CMT+Spring Transaction setup >>> as they would in a CMT alone, or Spring Tx alone setup. That >>> said, it can still be a viable and useful combination. Over a >>> period of some months, I migrated an app on JBoss from CMT EJB to >>> no EJB with Spring Tx wrapping service beans, and the CMT+Spring >>> Tx combo provided a valuable middle ground in the migration, in >>> the perdio when there were still some EJBs, but a lot had already >>> moved over. >>>=20 >>> Regards, Colin ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-09-02 18:42:18
|
Now wouldn't it be nice if HttpServletResponse.sendRedirect already = performed such a check and sent the appropriate status code... Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Seth Ladd Sent: Thursday, September 02, 2004 8:32 PM To: spr...@li... Subject: Re: [Springframework-developer] Status of 303 instead of 302 in RedirectView On Thu, 2 Sep 2004 15:30:53 +0200, j=FCrgen h=F6ller [werk3AT] <jue...@we...> wrote: > http://opensource.atlassian.com/projects/spring/browse/SPR-299 >=20 > I'm not intimately familar with the HTTP spec, so I can't really judge = this. >=20 > A possible compromise could be to just send 303 in case of a POST = request, and keep sending 302 via response.sendRedirect else. Thoughts? = Experiences? It also sounds like we should send 302 always for HTTP 1.0 clients.=20 If the client is HTTP 1.1 aware, then 302 for GET and 303 for POST sounds like what the RFC wants us to do. Seth ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Seth L. <set...@gm...> - 2004-09-02 18:31:44
|
On Thu, 2 Sep 2004 15:30:53 +0200, j=FCrgen h=F6ller [werk3AT] <jue...@we...> wrote: > http://opensource.atlassian.com/projects/spring/browse/SPR-299 >=20 > I'm not intimately familar with the HTTP spec, so I can't really judge th= is. >=20 > A possible compromise could be to just send 303 in case of a POST request= , and keep sending 302 via response.sendRedirect else. Thoughts? Experience= s? It also sounds like we should send 302 always for HTTP 1.0 clients.=20 If the client is HTTP 1.1 aware, then 302 for GET and 303 for POST sounds like what the RFC wants us to do. Seth |
|
From: <jue...@we...> - 2004-09-02 18:26:16
|
Have I missed the latest mail from Colin here? I can't see it on the = mailing list... Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of James Cook Sent: Thursday, September 02, 2004 8:11 PM To: spr...@li... Subject: RE: [Springframework-developer] flush() method on HibernateTemplate > -----Original Message----- > Of Colin Sampaleanu > In the end, I think it's somewhat contrived if some app has to > do a half dozen HibernateCallback cases where the only only operation > inside them is a flush() call. 2c. I don't have the code in fromt of me, but I believe we have been = using getSession().flush() in our DAO's when we needed this behavior. As Colin stated already, classes that extend HibernateDAOSupport probably don't = mind a Hibernate-specific functionality exposed in their superclass. I also = agree with him that it isn't the same thing as EAGER_FLUSH. ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: James C. <jim...@do...> - 2004-09-02 18:13:09
|
> -----Original Message----- > Of Colin Sampaleanu > In the end, I think it's somewhat contrived if some app has to > do a half dozen HibernateCallback cases where the only only operation > inside them is a flush() call. 2c. I don't have the code in fromt of me, but I believe we have been = using getSession().flush() in our DAO's when we needed this behavior. As Colin stated already, classes that extend HibernateDAOSupport probably don't = mind a Hibernate-specific functionality exposed in their superclass. I also = agree with him that it isn't the same thing as EAGER_FLUSH. |
|
From: bryan <nih...@gm...> - 2004-09-02 17:39:19
|
Apache ant has a very neat feature which supports conditional processing of targets based on the contents of a properties file. Are there any plans to support anything similar to this in the springframework ? --b |
|
From: <jue...@we...> - 2004-09-02 17:30:22
|
As far as I see, it won't break any code as long as you don't use the = "abstract" attribute... In that sense, it should be perfectly = backwards-compatible with existing bean definitions. I think it's = reasonable that a *modification* of your bean definitions might = introduce new behavior. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Rod Johnson Sent: Thursday, September 02, 2004 7:17 PM To: spr...@li... Subject: RE: [Springframework-developer] Abstract bean definitions I think this is a reasonable approach. However, it *will* break some = code. But I don't think it's unreasonable for such SPI-dependent code to be broken, so long as we clearly explain the rationale and impact in the release note and doco. I'm inclining towards extensive use of inner beans, which do address = most requirements for private beans. I guess there remains the case where multiple beans within one context reference a bean that should be = private. I don't think public/private should be considered for 1.1 final.=20 -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of j=FCrgen h=F6ller [werk3AT] Sent: 30 August 2004 19:12 To: spr...@li... Subject: Re: [Springframework-developer] Abstract bean definitions Well, getBeansOfType already ignores abstract beans: That method returns bean instances, so the only sensible thing to do here is to simply = ignore abstract beans whose type would match. =20 getBeanDefinitionNames() and getBeanDefinitionNames(type) do return = names of abstract beans too, though, just like getBeanDefinitionCount() includes abstract beans too. If you cast to ConfigurableListableBeanFactory, you = can fetch the BeanDefinition for a given name, which is also supposed to = work for abstract beans - this is needed by PropertyPlaceholderConfigurer, = for example. So for consistency, getBeanDefinitionNames more or less has to return names of abstract beans too. =20 Via ConfigurableListableBeanFactory's getBeanDefinition(name) method, = you can also check whether a bean definition is abstract now, if you = absolutely need to. However, I think that for all normal use cases, getBeansOfType = is what you usually want, as it also checks the type of FactoryBeans and returns concrete instances. So I don't think that the above is a = limitation. And everything's perfectly backwards-compatible as long as you don't = mark a bean "abstract" anyway... =20 Regarding public/private beans, there is a problem waiting there too: = Even private bean definitions need to be visible to ConfigurableListableBeanFactory, for PropertyPlaceholderConfigurer and = co. So should getBeanDefinitionCount and getBeanDefinitionNames include = private beans too? We could simply check in getBean and getBeansOfType to = exclude private beans, but that feels a bit odd... =20 Essentially, do we really need public/private beans now that we have abstract beans? getBeansOfType and autowiring by type already exclude abstract beans, and inner bean definitions solve the TransactionProxyFactoryBean autowiring problem (where both the proxy and = the target match by type). We should clarify the usage scenarios for private beans first, before worrying about them, I guess. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: Mo 30.08.2004 19:26 An: spr...@li... Betreff: Re: [Springframework-developer] Abstract bean definitions I'll update the docs accordingly. I agree about making a distinction between getting info for usage by = Spring, and by other users, but the usage semantics with only abstract and no public/private are a bit problematic. I assume even getBeanDefinitionNames(Class type); and getBeansOfType(Class type, boolean includePrototypes, boolean includeFactoryBeans) are going to return the abstract beans, right? There is a decent amount = of user code right now which uses these methods to get real live beans. If abstract beans come in as a result of these calls, and people have no = way to exclude them, it basically precludes using abstract beans for any = bean def hierarchies where somebody is going to be using these methods to get live beans... Colin j=FCrgen h=F6ller [werk3AT] wrote: >Rod, Colin, everybody, > >I've implemented an "abstract" attribute for <bean> tags in XML bean definitions. It works as expected in test cases. I've also adapted the "baseTxProxy" bean definitions in Petclinic and JPetStore (as introduced = by Colin) accordingly, marking them as "abstract" rather than "lazy-init". > >There's one issue with visibility, though: For consistency, an abstract bean definition is currently visible just like any other bean = definition: returned by ListableBeanFactory's getBeanDefinitionNames and ConfigurableBeanFactory's getBeanDefinition. On getBean, an BeanIsAbstractException gets thrown. > >We plan to introduce a "public" attribute for Spring 1.2: This could be used to make a bean private, be it abstract or not. IMO, these are effectively two separate concerns: I believe that we should treat them separately, i.e. not automatically make an abstract bean private. > >For example, a bean factory needs to be able to access a parent bean definition in an ancestor bean factory, even if that parent bean is = marked as "abstract" to never get instantiated directly. If an abstract parent = bean definition were automatically private, this wouldn't work. > >What do you think? I'll polish and commit my current implementation tonight, if there are no objections. As I said earlier, I'd like to = release 1.1 final by the end of this week: Abstract bean definitions is the last essential feature for that release. > >Juergen >=20 > ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java = Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java = Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Rod J. <ro...@in...> - 2004-09-02 17:17:51
|
I'll try to look at it now. It would be nice to get it in 1.1 final.=20 -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of j=FCrgen h=F6ller [werk3AT] Sent: 30 August 2004 11:24 To: spr...@li... Subject: [Springframework-developer] Cannot proxy classes lacking no-arg constructor using CGLIB Any progress on this issue? http://opensource.atlassian.com/projects/spring/browse/SPR-285 How much effort would it be to adapt our Cglib2AopProxy accordingly? = What Spring release do we plan this for? Juergen DI J=FCrgen H=F6ller Senior System Architect ______________________________________ werk3ATS - division systementwicklung werk3AT informations- und mediensysteme europaplatz 4 A - 4020 linz t. +43 (0) 732 71 65 29 502 f. +43 (0) 732 71 65 29 3 mailto:jue...@we... http://www.werk3at.com ______________________________________ werk3ATS - WIR ENTWICKELN ERFOLG ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java = Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Rod J. <ro...@in...> - 2004-09-02 17:17:50
|
I think this is a reasonable approach. However, it *will* break some = code. But I don't think it's unreasonable for such SPI-dependent code to be broken, so long as we clearly explain the rationale and impact in the release note and doco. I'm inclining towards extensive use of inner beans, which do address = most requirements for private beans. I guess there remains the case where multiple beans within one context reference a bean that should be = private. I don't think public/private should be considered for 1.1 final.=20 -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of j=FCrgen h=F6ller [werk3AT] Sent: 30 August 2004 19:12 To: spr...@li... Subject: Re: [Springframework-developer] Abstract bean definitions Well, getBeansOfType already ignores abstract beans: That method returns bean instances, so the only sensible thing to do here is to simply = ignore abstract beans whose type would match. =20 getBeanDefinitionNames() and getBeanDefinitionNames(type) do return = names of abstract beans too, though, just like getBeanDefinitionCount() includes abstract beans too. If you cast to ConfigurableListableBeanFactory, you = can fetch the BeanDefinition for a given name, which is also supposed to = work for abstract beans - this is needed by PropertyPlaceholderConfigurer, = for example. So for consistency, getBeanDefinitionNames more or less has to return names of abstract beans too. =20 Via ConfigurableListableBeanFactory's getBeanDefinition(name) method, = you can also check whether a bean definition is abstract now, if you = absolutely need to. However, I think that for all normal use cases, getBeansOfType = is what you usually want, as it also checks the type of FactoryBeans and returns concrete instances. So I don't think that the above is a = limitation. And everything's perfectly backwards-compatible as long as you don't = mark a bean "abstract" anyway... =20 Regarding public/private beans, there is a problem waiting there too: = Even private bean definitions need to be visible to ConfigurableListableBeanFactory, for PropertyPlaceholderConfigurer and = co. So should getBeanDefinitionCount and getBeanDefinitionNames include = private beans too? We could simply check in getBean and getBeansOfType to = exclude private beans, but that feels a bit odd... =20 Essentially, do we really need public/private beans now that we have abstract beans? getBeansOfType and autowiring by type already exclude abstract beans, and inner bean definitions solve the TransactionProxyFactoryBean autowiring problem (where both the proxy and = the target match by type). We should clarify the usage scenarios for private beans first, before worrying about them, I guess. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: Mo 30.08.2004 19:26 An: spr...@li... Betreff: Re: [Springframework-developer] Abstract bean definitions I'll update the docs accordingly. I agree about making a distinction between getting info for usage by = Spring, and by other users, but the usage semantics with only abstract and no public/private are a bit problematic. I assume even getBeanDefinitionNames(Class type); and getBeansOfType(Class type, boolean includePrototypes, boolean includeFactoryBeans) are going to return the abstract beans, right? There is a decent amount = of user code right now which uses these methods to get real live beans. If abstract beans come in as a result of these calls, and people have no = way to exclude them, it basically precludes using abstract beans for any = bean def hierarchies where somebody is going to be using these methods to get live beans... Colin j=FCrgen h=F6ller [werk3AT] wrote: >Rod, Colin, everybody, > >I've implemented an "abstract" attribute for <bean> tags in XML bean definitions. It works as expected in test cases. I've also adapted the "baseTxProxy" bean definitions in Petclinic and JPetStore (as introduced = by Colin) accordingly, marking them as "abstract" rather than "lazy-init". > >There's one issue with visibility, though: For consistency, an abstract bean definition is currently visible just like any other bean = definition: returned by ListableBeanFactory's getBeanDefinitionNames and ConfigurableBeanFactory's getBeanDefinition. On getBean, an BeanIsAbstractException gets thrown. > >We plan to introduce a "public" attribute for Spring 1.2: This could be used to make a bean private, be it abstract or not. IMO, these are effectively two separate concerns: I believe that we should treat them separately, i.e. not automatically make an abstract bean private. > >For example, a bean factory needs to be able to access a parent bean definition in an ancestor bean factory, even if that parent bean is = marked as "abstract" to never get instantiated directly. If an abstract parent = bean definition were automatically private, this wouldn't work. > >What do you think? I'll polish and commit my current implementation tonight, if there are no objections. As I said earlier, I'd like to = release 1.1 final by the end of this week: Abstract bean definitions is the last essential feature for that release. > >Juergen >=20 > ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java = Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java = Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-09-02 17:17:30
|
I completely agree that we should not recommend mixing strategies, but = rather concentrate on making JtaTransactionManager work within EJB BMT = or web components in all cases. BTW, I've just noticed that the problem with resuming a rollback-only = transaction on WebLogic will hardly ever happen when driven by Spring's = JtaTransactionManager: Spring keeps the rollback-only flag in its own = TransactionStatus object, applying it at commit time. The JTA = UserTransaction will just receive a setRollbackOnly call when a = participating subtransaction completes with a rollback. For example, the following sequence will work with JtaTransactionManager = on WebLogic, provided that everything's driven by Spring demarcation = (because of the workflow outlined above): - outer transaction begin - outer transaction setRollbackOnly - inner transaction (REQUIRES_NEW) begin - inner transaction (REQUIRES_NEW) commit - outer transaction commit Just scenarios like the following won't work, because the participating = transaction (REQUIRED) will mark the JTA transaction as rollback-only, = creating the resume problem on WebLogic after the new transaction = (REQUIRES_NEW) has completed: - outer transaction begin - inner transaction 1 (REQUIRED) begin - inner transaction 1 (REQUIRED) setRollbackOnly - inner transaction 2 (REQUIRES_NEW) begin - inner transaction 2 (REQUIRES_NEW) commit - outer transaction commit Thus, as long as Spring's JtaTransactionManager drives all transactions = itself (which is the case with EJB BMT or web components), there's just = a need for using WebLogicJtaTransactionManager in very specific cases. = For many transaction suspension use cases, the standard = JtaTransactionManager will work too. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of tho...@tr... Sent: Thursday, September 02, 2004 5:30 PM To: spr...@li... Subject: Re: [Springframework-developer] JTA transaction suspension on WebSphere Yes, but just because it works in one instance does not make it a good = practice :) I only used it because Eugene's test case was set up that way. From EJB 2.1 spec - 17.3.4 Enterprise Beans Using Container-Managed = Transaction Demarcation: "The enterprise bean's business methods, message listener methods, or = ejbTimeout method must not attempt to obtain or use the = javax.transaction.UserTransaction interface." So I think it would be wise not to mix strategies - either use J2EE = BMT/Spring declarative transactions or J2EE CMT. That way we can stay withing the = J2EE spec. If I have time this weekend I'll try to test these scenario with BMT on = WLS 8.1 and 7.0. Thomas Quoting Colin Sampaleanu <col...@ex...>: > > eu wrote: > > > So, now it is unclear if it does work on WLS 8 in CMT scenario? > > It does, as per Thomas's confirmation... > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <tho...@tr...> - 2004-09-02 15:31:38
|
Yes, but just because it works in one instance does not make it a good practice :) I only used it because Eugene's test case was set up that way. From EJB 2.1 spec - 17.3.4 Enterprise Beans Using Container-Managed Transaction Demarcation: "The enterprise beans business methods, message listener methods, or ejbTimeout method must not attempt to obtain or use the javax.transaction.UserTransaction interface." So I think it would be wise not to mix strategies - either use J2EE BMT/Spring declarative transactions or J2EE CMT. That way we can stay withing the J2EE spec. If I have time this weekend I'll try to test these scenario with BMT on WLS 8.1 and 7.0. Thomas Quoting Colin Sampaleanu <col...@ex...>: > > eu wrote: > > > So, now it is unclear if it does work on WLS 8 in CMT scenario? > > It does, as per Thomas's confirmation... > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Colin S. <col...@ex...> - 2004-09-02 15:12:14
|
eu wrote: > So, now it is unclear if it does work on WLS 8 in CMT scenario? It does, as per Thomas's confirmation... |
1239 messages has been excluded from this view by a project administrator.
