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: <al...@jt...> - 2005-03-06 23:34:26
|
<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:#901090; }.unittests-failure { fon=
t-family:arial,helvetica,sans-serif; font-size:8pt; color:#FF0000; }.checks=
tyle-oddrow { background-color:#CCCCCC }.checkstyle-data { font-family:aria=
l,helvetica,sans-serif; font-size:8pt; color:#000000; }.checkstyle-sectionh=
eader { background-color:#000066; font-family:arial,helvetica,sans-serif; f=
ont-size:10pt; color:#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.219</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build: </span>03/07/2005 00:16:19</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>22 minutes 35 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed: </span>03/06/2005 09:48:38</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try: </span>Method setAttribute() now enforces Serializable attributes=
.</td></tr></table><p>
<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-data">Note: S=
ome input files use or override a deprecated API.<br class=3D"none"/>Note: =
Recompile with -deprecation for details.<br class=3D"none"/>Note: /jteam/bu=
ild2/checkout/spring/spring/mock/org/springframework/mock/web/MockHttpSessi=
on.java uses or overrides a deprecated API.<br class=3D"none"/>Note: Recomp=
ile with -deprecation for details.<br class=3D"none"/>Note: Some input file=
s use or override a deprecated API.<br class=3D"none"/>Note: Recompile with=
-deprecation for details.<br class=3D"none"/></pre></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"><tr><td class=
=3D"compile-sectionheader"> Javadoc Errors/War=
nings: (31) </td></tr><tr><td><pre class=3D"compile-data=
">/jteam/build2/checkout/spring/spring/src/org/springframework/jdbc/support=
/lob/OracleLobHandler.java:76: warning - Tag @see: reference not found: ora=
cle.sql.BLOB<br/>/jteam/build2/checkout/spring/spring/src/org/springframewo=
rk/jdbc/support/lob/OracleLobHandler.java:76: warning - Tag @see: reference=
not found: oracle.sql.CLOB<br/>/jteam/build2/checkout/spring/spring/src/or=
g/springframework/jdbc/support/lob/OracleLobHandler.java:115: warning - Tag=
@see: reference not found: oracle.sql.BLOB#DURATION_SESSION<br/>/jteam/bui=
ld2/checkout/spring/spring/src/org/springframework/jdbc/support/lob/OracleL=
obHandler.java:115: warning - Tag @see: reference not found: oracle.sql.BLO=
B#MODE_READWRITE<br/>/jteam/build2/checkout/spring/spring/src/org/springfra=
mework/jdbc/support/lob/OracleLobHandler.java:115: warning - Tag @see: refe=
rence not found: oracle.sql.CLOB#DURATION_SESSION<br/>/jteam/build2/checkou=
t/spring/spring/src/org/springframework/jdbc/support/lob/OracleLobHandler.j=
ava:115: warning - Tag @see: reference not found: oracle.sql.CLOB#MODE_READ=
WRITE<br/>/jteam/build2/checkout/spring/spring/src/org/springframework/jdbc=
/support/lob/OracleLobHandler.java:154: warning - Tag @see: reference not f=
ound: oracle.jdbc.OracleConnection<br/>/jteam/build2/checkout/spring/spring=
/src/org/springframework/jdbc/support/lob/OracleLobHandler.java:164: warnin=
g - Tag @see: reference not found: oracle.sql.BLOB#createTemporary<br/>/jte=
am/build2/checkout/spring/spring/src/org/springframework/jdbc/support/lob/O=
racleLobHandler.java:164: warning - Tag @see: reference not found: oracle.s=
ql.CLOB#createTemporary<br/>/jteam/build2/checkout/spring/spring/src/org/sp=
ringframework/jdbc/support/nativejdbc/JBossNativeJdbcExtractor.java:49: war=
ning - Tag @see: reference not found: org.jboss.resource.adapter.jdbc.Wrapp=
edConnection#getUnderlyingConnection<br/>/jteam/build2/checkout/spring/spri=
ng/src/org/springframework/jdbc/support/nativejdbc/JBossNativeJdbcExtractor=
.java:49: warning - Tag @see: reference not found: org.jboss.resource.adapt=
er.jdbc.WrappedStatement#getUnderlyingStatement<br/>/jteam/build2/checkout/=
spring/spring/src/org/springframework/jdbc/support/nativejdbc/JBossNativeJd=
bcExtractor.java:49: warning - Tag @see: reference not found: org.jboss.res=
ource.adapter.jdbc.WrappedResultSet#getUnderlyingResultSet<br/>/jteam/build=
2/checkout/spring/spring/src/org/springframework/jdbc/support/nativejdbc/We=
bLogicNativeJdbcExtractor.java:45: warning - Tag @see: reference not found:=
weblogic.jdbc.extensions.WLConnection#getVendorConnection<br/>/jteam/build=
2/checkout/spring/spring/src/org/springframework/jdbc/support/nativejdbc/We=
bSphereNativeJdbcExtractor.java:49: warning - Tag @see: reference not found=
: com.ibm.ws.rsadapter.jdbc.WSJdbcConnection<br/>/jteam/build2/checkout/spr=
ing/spring/src/org/springframework/jdbc/support/nativejdbc/WebSphereNativeJ=
dbcExtractor.java:49: warning - Tag @see: reference not found: com.ibm.ws.r=
sadapter.jdbc.WSJdbcUtil#getNativeConnection<br/>/jteam/build2/checkout/spr=
ing/spring/src/org/springframework/jdbc/support/nativejdbc/WebSphereNativeJ=
dbcExtractor.java:49: warning - Tag @see: reference not found: com.ibm.ejs.=
cm.proxy.ConnectionProxy#getPhysicalConnection<br/>/jteam/build2/checkout/s=
pring/spring/src/org/springframework/orm/hibernate3/LocalSessionFactoryBean=
.java:339: warning - Tag @see: reference not found: org.hibernate.UserType<=
br/>/jteam/build2/checkout/spring/spring/src/org/springframework/orm/hibern=
ate3/SessionFactoryUtils.java:155: warning - Tag @see: reference not found:=
org.hibernate.impl.SessionFactoryImpl<br/>/jteam/build2/checkout/spring/sp=
ring/src/org/springframework/orm/hibernate3/SessionFactoryUtils.java:155: w=
arning - Tag @see: reference not found: org.hibernate.jca.JCASessionFactory=
Impl<br/>/jteam/build2/checkout/spring/spring/src/org/springframework/orm/i=
batis/SqlMapClientFactoryBean.java:198: warning - Tag @see: reference not f=
ound: com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTransactionConfig<br/>/=
jteam/build2/checkout/spring/spring/src/org/springframework/orm/ibatis/SqlM=
apClientFactoryBean.java:198: warning - Tag @see: reference not found: com.=
ibatis.sqlmap.engine.transaction.jta.JtaTransactionConfig<br/>/jteam/build2=
/checkout/spring/spring/src/org/springframework/orm/ibatis/SqlMapClientFact=
oryBean.java:226: warning - Tag @see: reference not found: com.ibatis.sqlma=
p.engine.transaction.jdbc.JdbcTransactionConfig<br/>/jteam/build2/checkout/=
spring/spring/src/org/springframework/orm/ibatis/SqlMapClientFactoryBean.ja=
va:226: warning - Tag @see: reference not found: com.ibatis.sqlmap.engine.t=
ransaction.jta.JtaTransactionConfig<br/>/jteam/build2/checkout/spring/sprin=
g/src/org/springframework/transaction/jta/WebLogicJtaTransactionManager.jav=
a:66: warning - Tag @see: reference not found: weblogic.transaction.Transac=
tionManager#forceResume<br/>/jteam/build2/checkout/spring/spring/src/org/sp=
ringframework/transaction/jta/WebLogicServerTransactionManagerFactoryBean.j=
ava:45: warning - Tag @see: reference not found: weblogic.transaction.TxHel=
per#getTransactionManager<br/>/jteam/build2/checkout/spring/spring/src/org/=
springframework/transaction/jta/WebSphereTransactionManagerFactoryBean.java=
:49: warning - Tag @see: reference not found: com.ibm.ws.Transaction.Transa=
ctionManagerFactory#getTransactionManager<br/>/jteam/build2/checkout/spring=
/spring/src/org/springframework/transaction/jta/WebSphereTransactionManager=
FactoryBean.java:49: warning - Tag @see: reference not found: com.ibm.ejs.j=
ts.jta.JTSXA#getTransactionManager<br/>/jteam/build2/checkout/spring/spring=
/src/org/springframework/transaction/jta/WebSphereTransactionManagerFactory=
Bean.java:49: warning - Tag @see: reference not found: com.ibm.ejs.jts.jta.=
TransactionManagerFactory#getTransactionManager<br/>/jteam/build2/checkout/=
spring/spring/src/org/springframework/util/ObjectUtils.java:31: warning - T=
ag @see: reference not found: org.apache.commons.lang.ObjectUtils<br/>/jtea=
m/build2/checkout/spring/spring/src/org/springframework/util/StringUtils.ja=
va:47: warning - Tag @see: reference not found: org.apache.commons.lang.Str=
ingUtils<br/>/jteam/build2/checkout/spring/spring/src/org/springframework/w=
eb/servlet/handler/metadata/PathMap.java:31: warning - @@org.apache.commons=
.attributes.Indexed() is an unknown tag.<br/></pre></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"unittests-sectionheader"> =
Unit Tests: (2769) </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">testHelpPage</td><td width=
=3D"40%" class=3D"unittests-data">org.springframework.apptests.jpetstore.Al=
lTests</td></tr><tr class=3D"unittests-oddrow"><td class=3D"unittests-data"=
> failure </td><td width=3D"40%" class=3D"unittes=
ts-data">testPurchase</td><td width=3D"40%" class=3D"unittests-data">org.sp=
ringframework.apptests.jpetstore.AllTests</td></tr><tr><td class=3D"unittes=
ts-data"> failure </td><td width=3D"40%" class=3D=
"unittests-data">testSearch</td><td width=3D"40%" class=3D"unittests-data">=
org.springframework.apptests.jpetstore.AllTests</td></tr><tr class=3D"unitt=
ests-oddrow"><td class=3D"unittests-data"> failure =
</td><td width=3D"40%" class=3D"unittests-data">testHelpPage</td><td widt=
h=3D"40%" class=3D"unittests-data">org.springframework.apptests.jpetstore.A=
llTests</td></tr><tr><td class=3D"unittests-data"> failure =
</td><td width=3D"40%" class=3D"unittests-data">testPurchase</td>=
<td width=3D"40%" class=3D"unittests-data">org.springframework.apptests.jpe=
tstore.AllTests</td></tr><tr class=3D"unittests-oddrow"><td class=3D"unitte=
sts-data"> failure </td><td width=3D"40%" class=
=3D"unittests-data">testSearch</td><td width=3D"40%" class=3D"unittests-dat=
a">org.springframework.apptests.jpetstore.AllTests</td></tr></table></td></=
tr><tr></tr><tr><td colspan=3D"2"> </td></tr><tr><td colspan=3D"4" cla=
ss=3D"unittests-sectionheader"> Unit Test Error De=
tails: (6) </td></tr><tr><td class=3D"unittests-data" c=
olspan=3D"2"> Test: testHelpPage</td></tr><tr><td class=
=3D"unittests-data" colspan=3D"2"> Class: org.springfra=
mework.apptests.jpetstore.AllTests</td></tr><tr><td class=3D"unittests-data=
" colspan=3D"2"> Type: junit.framework.AssertionFailedError<=
/td></tr><tr><td class=3D"unittests-data" colspan=3D"2"> Mes=
sage: Exception: com.meterware.httpunit.HttpInternalErrorException: Error o=
n HTTP request: 500 Internal Error [http://localhost:13084/jpetstore/shop/h=
elp.do?param=3Dfreemarker]</td></tr><tr><td class=3D"unittests-failure" col=
span=3D"2"><pre>junit.framework.AssertionFailedError: Exception: com.meterw=
are.httpunit.HttpInternalErrorException: Error on HTTP request: 500 Interna=
l Error [http://localhost:13084/jpetstore/shop/help.do?param=3Dfreemarker]<=
br>=09at org.springframework.apptests.jpetstore.AllTests.testHelpPage(Unkno=
wn Source)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Met=
hod)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces=
sorImpl.java:39)<br>=09at sun.reflect.DelegatingMethodAccessorImpl.invoke(D=
elegatingMethodAccessorImpl.java:25)<br>=09at java.lang.Thread.run(Thread.j=
ava:534)<br></pre></td></tr><tr><td class=3D"unittests-data" colspan=3D"2">=
Test: testPurchase</td></tr><tr><td class=3D"unittests=
-data" colspan=3D"2"> Class: org.springframework.apptes=
ts.jpetstore.AllTests</td></tr><tr><td class=3D"unittests-data" colspan=3D"=
2"> Type: junit.framework.AssertionFailedError</td></tr><tr>=
<td class=3D"unittests-data" colspan=3D"2"> Message: Excepti=
on: com.meterware.httpunit.HttpInternalErrorException: Error on HTTP reques=
t: 500 Internal Error [http://localhost:13084/jpetstore/shop/index.do]</td>=
</tr><tr><td class=3D"unittests-failure" colspan=3D"2"><pre>junit.framework=
.AssertionFailedError: Exception: com.meterware.httpunit.HttpInternalErrorE=
xception: Error on HTTP request: 500 Internal Error [http://localhost:13084=
/jpetstore/shop/index.do]<br>=09at org.springframework.apptests.jpetstore.A=
llTests.testPurchase(Unknown Source)<br>=09at sun.reflect.NativeMethodAcces=
sorImpl.invoke0(Native Method)<br>=09at sun.reflect.NativeMethodAccessorImp=
l.invoke(NativeMethodAccessorImpl.java:39)<br>=09at sun.reflect.DelegatingM=
ethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)<br>=09at jav=
a.lang.Thread.run(Thread.java:534)<br></pre></td></tr><tr><td class=3D"unit=
tests-data" colspan=3D"2"> Test: testSearch</td></tr><t=
r><td class=3D"unittests-data" colspan=3D"2"> Class: or=
g.springframework.apptests.jpetstore.AllTests</td></tr><tr><td class=3D"uni=
ttests-data" colspan=3D"2"> Type: junit.framework.AssertionF=
ailedError</td></tr><tr><td class=3D"unittests-data" colspan=3D"2"> =
Message: Exception: com.meterware.httpunit.HttpInternalErrorExcepti=
on: Error on HTTP request: 500 Internal Error [http://localhost:13084/jpets=
tore/shop/index.do]</td></tr><tr><td class=3D"unittests-failure" colspan=3D=
"2"><pre>junit.framework.AssertionFailedError: Exception: com.meterware.htt=
punit.HttpInternalErrorException: Error on HTTP request: 500 Internal Error=
[http://localhost:13084/jpetstore/shop/index.do]<br>=09at org.springframew=
ork.apptests.jpetstore.AllTests.testSearch(Unknown Source)<br>=09at sun.ref=
lect.NativeMethodAccessorImpl.invoke0(Native Method)<br>=09at sun.reflect.N=
ativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)<br>=09at s=
un.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl=
.java:25)<br>=09at java.lang.Thread.run(Thread.java:534)<br></pre></td></tr=
><tr><td class=3D"unittests-data" colspan=3D"2"> Test: =
testHelpPage</td></tr><tr><td class=3D"unittests-data" colspan=3D"2"> =
Class: org.springframework.apptests.jpetstore.AllTests</td><=
/tr><tr><td class=3D"unittests-data" colspan=3D"2"> Type: ju=
nit.framework.AssertionFailedError</td></tr><tr><td class=3D"unittests-data=
" colspan=3D"2"> Message: Exception: com.meterware.httpunit.=
HttpInternalErrorException: Error on HTTP request: 500 Internal Error [http=
://localhost:13084/jpetstore/shop/help.do?param=3Dfreemarker]</td></tr><tr>=
<td class=3D"unittests-failure" colspan=3D"2"><pre>junit.framework.Assertio=
nFailedError: Exception: com.meterware.httpunit.HttpInternalErrorException:=
Error on HTTP request: 500 Internal Error [http://localhost:13084/jpetstor=
e/shop/help.do?param=3Dfreemarker]<br>=09at org.springframework.apptests.jp=
etstore.AllTests.testHelpPage(Unknown Source)<br>=09at sun.reflect.NativeMe=
thodAccessorImpl.invoke0(Native Method)<br>=09at sun.reflect.NativeMethodAc=
cessorImpl.invoke(NativeMethodAccessorImpl.java:39)<br>=09at sun.reflect.De=
legatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)<br>=
=09at java.lang.Thread.run(Thread.java:534)<br></pre></td></tr><tr><td clas=
s=3D"unittests-data" colspan=3D"2"> Test: testPurchase<=
/td></tr><tr><td class=3D"unittests-data" colspan=3D"2"> Cla=
ss: org.springframework.apptests.jpetstore.AllTests</td></tr><tr><td c=
lass=3D"unittests-data" colspan=3D"2"> Type: junit.framework=
.AssertionFailedError</td></tr><tr><td class=3D"unittests-data" colspan=3D"=
2"> Message: Exception: com.meterware.httpunit.HttpInternalE=
rrorException: Error on HTTP request: 500 Internal Error [http://localhost:=
13084/jpetstore/shop/index.do]</td></tr><tr><td class=3D"unittests-failure"=
colspan=3D"2"><pre>junit.framework.AssertionFailedError: Exception: com.me=
terware.httpunit.HttpInternalErrorException: Error on HTTP request: 500 Int=
ernal Error [http://localhost:13084/jpetstore/shop/index.do]<br>=09at org.s=
pringframework.apptests.jpetstore.AllTests.testPurchase(Unknown Source)<br>=
=09at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br>=09at =
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3=
9)<br>=09at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMetho=
dAccessorImpl.java:25)<br>=09at java.lang.Thread.run(Thread.java:534)<br></=
pre></td></tr><tr><td class=3D"unittests-data" colspan=3D"2"> =
Test: testSearch</td></tr><tr><td class=3D"unittests-data" colspan=
=3D"2"> Class: org.springframework.apptests.jpetstore.A=
llTests</td></tr><tr><td class=3D"unittests-data" colspan=3D"2"> =
Type: junit.framework.AssertionFailedError</td></tr><tr><td class=3D"u=
nittests-data" colspan=3D"2"> Message: Exception: com.meterw=
are.httpunit.HttpInternalErrorException: Error on HTTP request: 500 Interna=
l Error [http://localhost:13084/jpetstore/shop/index.do]</td></tr><tr><td c=
lass=3D"unittests-failure" colspan=3D"2"><pre>junit.framework.AssertionFail=
edError: Exception: com.meterware.httpunit.HttpInternalErrorException: Erro=
r on HTTP request: 500 Internal Error [http://localhost:13084/jpetstore/sho=
p/index.do]<br>=09at org.springframework.apptests.jpetstore.AllTests.testSe=
arch(Unknown Source)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke0(=
Native Method)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke(NativeM=
ethodAccessorImpl.java:39)<br>=09at sun.reflect.DelegatingMethodAccessorImp=
l.invoke(DelegatingMethodAccessorImpl.java:25)<br>=09at java.lang.Thread.ru=
n(Thread.java:534)<br></pre></td></tr><tr><td colspan=3D"2"> </td></tr=
></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"1" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"6" class=3D"modifications-sectionheader"> =
Modifications since last build: =
(6) </td></tr><tr class=3D"modifications-evenrow"><td c=
lass=3D"modifications-data">modified</td><td class=3D"modifications-data">k=
lr8</td><td class=3D"modifications-data">sandbox/src/org/springframework/we=
b/flow/FlowSession.java</td><td class=3D"modifications-data">Method setAttr=
ibute() now enforces Serializable attributes.</td></tr><tr class=3D"modific=
ations-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"m=
odifications-data">klr8</td><td class=3D"modifications-data">sandbox/src/or=
g/springframework/web/flow/FlowExecutionStack.java</td><td class=3D"modific=
ations-data">Improved rehydration code.</td></tr><tr class=3D"modifications=
-evenrow"><td class=3D"modifications-data">modified</td><td class=3D"modifi=
cations-data">klr8</td><td class=3D"modifications-data">sandbox/src/org/spr=
ingframework/web/flow/FlowSession.java</td><td class=3D"modifications-data"=
>Improved rehydration code.</td></tr><tr class=3D"modifications-oddrow"><td=
class=3D"modifications-data">modified</td><td class=3D"modifications-data"=
>klr8</td><td class=3D"modifications-data">sandbox/test/org/springframework=
/web/flow/FlowExecutionStackTests.java</td><td class=3D"modifications-data"=
>Improved rehydration code.</td></tr><tr class=3D"modifications-evenrow"><t=
d class=3D"modifications-data">modified</td><td class=3D"modifications-data=
">klr8</td><td class=3D"modifications-data">.classpath</td><td class=3D"mod=
ifications-data">Added hibernate3.jar to the classpath to make everything c=
ompile again.</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modi=
fications-data">modified</td><td class=3D"modifications-data">jhoeller</td>=
<td class=3D"modifications-data">changelog.txt</td><td class=3D"modificatio=
ns-data">added Hibernate3 support, removed deprecated classes and methods</=
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: (16) </td>=
</tr><tr><td class=3D"distributables-data">Building jar: /jteam/build2/chec=
kout/spring/spring/dist/spring-core.jar</td></tr><tr class=3D"distributable=
s-oddrow"><td class=3D"distributables-data">Building jar: /jteam/build2/che=
ckout/spring/spring/dist/spring-aop.jar</td></tr><tr><td class=3D"distribut=
ables-data">Building jar: /jteam/build2/checkout/spring/spring/dist/spring-=
context.jar</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distr=
ibutables-data">Building jar: /jteam/build2/checkout/spring/spring/dist/spr=
ing-dao.jar</td></tr><tr><td class=3D"distributables-data">Building jar: /j=
team/build2/checkout/spring/spring/dist/spring-orm.jar</td></tr><tr class=
=3D"distributables-oddrow"><td class=3D"distributables-data">Building jar: =
/jteam/build2/checkout/spring/spring/dist/spring-web.jar</td></tr><tr><td c=
lass=3D"distributables-data">Building jar: /jteam/build2/checkout/spring/sp=
ring/dist/spring-webmvc.jar</td></tr><tr class=3D"distributables-oddrow"><t=
d class=3D"distributables-data">Building jar: /jteam/build2/checkout/spring=
/spring/dist/spring.jar</td></tr><tr><td class=3D"distributables-data">Buil=
ding jar: /jteam/build2/checkout/spring/spring/dist/spring-mock.jar</td></t=
r><tr class=3D"distributables-oddrow"><td class=3D"distributables-data">Bui=
lding war: /jteam/build2/checkout/spring/spring/autobuilds/apps/buildtest/d=
ist/buildtest.war</td></tr><tr><td class=3D"distributables-data">Building w=
ar: /jteam/build2/checkout/spring/spring/autobuilds/apps/buildtest/dist/bui=
ldtest.war</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distri=
butables-data">Building war: /jteam/build2/checkout/spring/spring/autobuild=
s/apps/buildtest/dist/buildtest.war</td></tr><tr><td class=3D"distributable=
s-data">Building jar: /jteam/build2/checkout/spring/spring/autobuilds/apps/=
jpetstore/war/WEB-INF/lib/jpetstore.jar</td></tr><tr class=3D"distributable=
s-oddrow"><td class=3D"distributables-data">Building war: /jteam/build2/che=
ckout/spring/spring/autobuilds/apps/jpetstore/dist/jpetstore.war</td></tr><=
tr><td class=3D"distributables-data">Building jar: /jteam/build2/checkout/s=
pring/spring/autobuilds/apps/jpetstore/war/WEB-INF/lib/jpetstore.jar</td></=
tr><tr class=3D"distributables-oddrow"><td class=3D"distributables-data">Bu=
ilding war: /jteam/build2/checkout/spring/spring/autobuilds/apps/jpetstore/=
dist/jpetstore.war</td></tr></table>
</body></html> |
|
From: Thomas R. <tho...@tr...> - 2005-03-06 01:48:43
|
Juergen I added that interface because, originally, during Geronimo integration we were looking to hook into the registration of the MBeans. It turns out this is no longer necessary so I guess we can just push registration back into MBeanExporter and remove RegistrationStrategy altogether. I don't think it has any other use case beyond the one I described and that is no longer required. My vote is to remove it. Rob (from Thomas' laptop) On Mar 5, 2005, at 6:35 PM, Juergen Hoeller wrote: > Rob, > > I've noticed that you've added a RegistrationStrategy interface to the > JMX > support. I'd like to suggest a couple of refinements: > > * MBeanExporter shouldn't modify the state of a passed-in > RegistrationStrategy instance: the passed-in instance is supposed to be > fully initialized. > > * Consequently, the MBeanServerAwareRegistrationStrategy subinterface > is not > ideal. I would prefer registerMBean and unregisterMBean methods with an > MBeanServer passed in as argument (which implementations can choose to > ignore). > > * DefaultRegistrationStrategy should probably be renamed to > SimpleRegistrationStrategy. What it really does is straighforward > delegation > to the MBeanServer: the simplest registration strategy that might > possibly > work. > > * Let's move the RegistrationStrategy interface and the > DefaultRegistrationStrategy class to the "jmx" package itself. Those > two > classes are not really worth their own subpackage, and the root > package is > still pretty thin anyway. > > What do you think? I'm also curious what alternative > RegistrationStrategy > implementations you have in mind (i.e. why you decided to introduce the > strategy). > > Once we've nailed down those remaining issues, I'll move the JMX > support > over to the main sources. Spring 1.2 RC1 is just around the corner :-) > > Juergen > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Juergen H. <ju...@in...> - 2005-03-05 23:36:00
|
Rob, I've noticed that you've added a RegistrationStrategy interface to the JMX support. I'd like to suggest a couple of refinements: * MBeanExporter shouldn't modify the state of a passed-in RegistrationStrategy instance: the passed-in instance is supposed to be fully initialized. * Consequently, the MBeanServerAwareRegistrationStrategy subinterface is not ideal. I would prefer registerMBean and unregisterMBean methods with an MBeanServer passed in as argument (which implementations can choose to ignore). * DefaultRegistrationStrategy should probably be renamed to SimpleRegistrationStrategy. What it really does is straighforward delegation to the MBeanServer: the simplest registration strategy that might possibly work. * Let's move the RegistrationStrategy interface and the DefaultRegistrationStrategy class to the "jmx" package itself. Those two classes are not really worth their own subpackage, and the root package is still pretty thin anyway. What do you think? I'm also curious what alternative RegistrationStrategy implementations you have in mind (i.e. why you decided to introduce the strategy). Once we've nailed down those remaining issues, I'll move the JMX support over to the main sources. Spring 1.2 RC1 is just around the corner :-) Juergen |
|
From: <al...@jt...> - 2005-03-05 23:32:54
|
<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:#901090; }.unittests-failure { fon=
t-family:arial,helvetica,sans-serif; font-size:8pt; color:#FF0000; }.checks=
tyle-oddrow { background-color:#CCCCCC }.checkstyle-data { font-family:aria=
l,helvetica,sans-serif; font-size:8pt; color:#000000; }.checkstyle-sectionh=
eader { background-color:#000066; font-family:arial,helvetica,sans-serif; f=
ont-size:10pt; color:#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.218</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build: </span>03/06/2005 00:15:59</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>21 minutes 33 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed: </span>03/05/2005 16:48:13</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try: </span>JavaDoc.</td></tr></table><p>
<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-data">Note: S=
ome input files use or override a deprecated API.<br class=3D"none"/>Note: =
Recompile with -deprecation for details.<br class=3D"none"/>Note: /jteam/bu=
ild2/checkout/spring/spring/mock/org/springframework/mock/web/MockHttpSessi=
on.java uses or overrides a deprecated API.<br class=3D"none"/>Note: Recomp=
ile with -deprecation for details.<br class=3D"none"/>Note: Some input file=
s use or override a deprecated API.<br class=3D"none"/>Note: Recompile with=
-deprecation for details.<br class=3D"none"/></pre></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"><tr><td class=
=3D"compile-sectionheader"> Javadoc Errors/War=
nings: (28) </td></tr><tr><td><pre class=3D"compile-data=
">/jteam/build2/checkout/spring/spring/src/org/springframework/jdbc/support=
/lob/OracleLobHandler.java:76: warning - Tag @see: reference not found: ora=
cle.sql.BLOB<br/>/jteam/build2/checkout/spring/spring/src/org/springframewo=
rk/jdbc/support/lob/OracleLobHandler.java:76: warning - Tag @see: reference=
not found: oracle.sql.CLOB<br/>/jteam/build2/checkout/spring/spring/src/or=
g/springframework/jdbc/support/lob/OracleLobHandler.java:115: warning - Tag=
@see: reference not found: oracle.sql.BLOB#DURATION_SESSION<br/>/jteam/bui=
ld2/checkout/spring/spring/src/org/springframework/jdbc/support/lob/OracleL=
obHandler.java:115: warning - Tag @see: reference not found: oracle.sql.BLO=
B#MODE_READWRITE<br/>/jteam/build2/checkout/spring/spring/src/org/springfra=
mework/jdbc/support/lob/OracleLobHandler.java:115: warning - Tag @see: refe=
rence not found: oracle.sql.CLOB#DURATION_SESSION<br/>/jteam/build2/checkou=
t/spring/spring/src/org/springframework/jdbc/support/lob/OracleLobHandler.j=
ava:115: warning - Tag @see: reference not found: oracle.sql.CLOB#MODE_READ=
WRITE<br/>/jteam/build2/checkout/spring/spring/src/org/springframework/jdbc=
/support/lob/OracleLobHandler.java:154: warning - Tag @see: reference not f=
ound: oracle.jdbc.OracleConnection<br/>/jteam/build2/checkout/spring/spring=
/src/org/springframework/jdbc/support/lob/OracleLobHandler.java:164: warnin=
g - Tag @see: reference not found: oracle.sql.BLOB#createTemporary<br/>/jte=
am/build2/checkout/spring/spring/src/org/springframework/jdbc/support/lob/O=
racleLobHandler.java:164: warning - Tag @see: reference not found: oracle.s=
ql.CLOB#createTemporary<br/>/jteam/build2/checkout/spring/spring/src/org/sp=
ringframework/jdbc/support/nativejdbc/JBossNativeJdbcExtractor.java:49: war=
ning - Tag @see: reference not found: org.jboss.resource.adapter.jdbc.Wrapp=
edConnection#getUnderlyingConnection<br/>/jteam/build2/checkout/spring/spri=
ng/src/org/springframework/jdbc/support/nativejdbc/JBossNativeJdbcExtractor=
.java:49: warning - Tag @see: reference not found: org.jboss.resource.adapt=
er.jdbc.WrappedStatement#getUnderlyingStatement<br/>/jteam/build2/checkout/=
spring/spring/src/org/springframework/jdbc/support/nativejdbc/JBossNativeJd=
bcExtractor.java:49: warning - Tag @see: reference not found: org.jboss.res=
ource.adapter.jdbc.WrappedResultSet#getUnderlyingResultSet<br/>/jteam/build=
2/checkout/spring/spring/src/org/springframework/jdbc/support/nativejdbc/We=
bLogicNativeJdbcExtractor.java:45: warning - Tag @see: reference not found:=
weblogic.jdbc.extensions.WLConnection#getVendorConnection<br/>/jteam/build=
2/checkout/spring/spring/src/org/springframework/jdbc/support/nativejdbc/We=
bSphereNativeJdbcExtractor.java:49: warning - Tag @see: reference not found=
: com.ibm.ws.rsadapter.jdbc.WSJdbcConnection<br/>/jteam/build2/checkout/spr=
ing/spring/src/org/springframework/jdbc/support/nativejdbc/WebSphereNativeJ=
dbcExtractor.java:49: warning - Tag @see: reference not found: com.ibm.ws.r=
sadapter.jdbc.WSJdbcUtil#getNativeConnection<br/>/jteam/build2/checkout/spr=
ing/spring/src/org/springframework/jdbc/support/nativejdbc/WebSphereNativeJ=
dbcExtractor.java:49: warning - Tag @see: reference not found: com.ibm.ejs.=
cm.proxy.ConnectionProxy#getPhysicalConnection<br/>/jteam/build2/checkout/s=
pring/spring/src/org/springframework/orm/ibatis/SqlMapClientFactoryBean.jav=
a:198: warning - Tag @see: reference not found: com.ibatis.sqlmap.engine.tr=
ansaction.jdbc.JdbcTransactionConfig<br/>/jteam/build2/checkout/spring/spri=
ng/src/org/springframework/orm/ibatis/SqlMapClientFactoryBean.java:198: war=
ning - Tag @see: reference not found: com.ibatis.sqlmap.engine.transaction.=
jta.JtaTransactionConfig<br/>/jteam/build2/checkout/spring/spring/src/org/s=
pringframework/orm/ibatis/SqlMapClientFactoryBean.java:226: warning - Tag @=
see: reference not found: com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTra=
nsactionConfig<br/>/jteam/build2/checkout/spring/spring/src/org/springframe=
work/orm/ibatis/SqlMapClientFactoryBean.java:226: warning - Tag @see: refer=
ence not found: com.ibatis.sqlmap.engine.transaction.jta.JtaTransactionConf=
ig<br/>/jteam/build2/checkout/spring/spring/src/org/springframework/transac=
tion/jta/WebLogicJtaTransactionManager.java:66: warning - Tag @see: referen=
ce not found: weblogic.transaction.TransactionManager#forceResume<br/>/jtea=
m/build2/checkout/spring/spring/src/org/springframework/transaction/jta/Web=
LogicServerTransactionManagerFactoryBean.java:45: warning - Tag @see: refer=
ence not found: weblogic.transaction.TxHelper#getTransactionManager<br/>/jt=
eam/build2/checkout/spring/spring/src/org/springframework/transaction/jta/W=
ebSphereTransactionManagerFactoryBean.java:49: warning - Tag @see: referenc=
e not found: com.ibm.ws.Transaction.TransactionManagerFactory#getTransactio=
nManager<br/>/jteam/build2/checkout/spring/spring/src/org/springframework/t=
ransaction/jta/WebSphereTransactionManagerFactoryBean.java:49: warning - Ta=
g @see: reference not found: com.ibm.ejs.jts.jta.JTSXA#getTransactionManage=
r<br/>/jteam/build2/checkout/spring/spring/src/org/springframework/transact=
ion/jta/WebSphereTransactionManagerFactoryBean.java:49: warning - Tag @see:=
reference not found: com.ibm.ejs.jts.jta.TransactionManagerFactory#getTran=
sactionManager<br/>/jteam/build2/checkout/spring/spring/src/org/springframe=
work/util/ObjectUtils.java:31: warning - Tag @see: reference not found: org=
.apache.commons.lang.ObjectUtils<br/>/jteam/build2/checkout/spring/spring/s=
rc/org/springframework/util/StringUtils.java:47: warning - Tag @see: refere=
nce not found: org.apache.commons.lang.StringUtils<br/>/jteam/build2/checko=
ut/spring/spring/src/org/springframework/web/servlet/handler/metadata/PathM=
ap.java:31: warning - @@org.apache.commons.attributes.Indexed() is an unkno=
wn tag.<br/></pre></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"unittests-sectionheader"> =
Unit Tests: (2619) </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">testHelpPage</td><td width=
=3D"40%" class=3D"unittests-data">org.springframework.apptests.jpetstore.Al=
lTests</td></tr><tr class=3D"unittests-oddrow"><td class=3D"unittests-data"=
> failure </td><td width=3D"40%" class=3D"unittes=
ts-data">testPurchase</td><td width=3D"40%" class=3D"unittests-data">org.sp=
ringframework.apptests.jpetstore.AllTests</td></tr><tr><td class=3D"unittes=
ts-data"> failure </td><td width=3D"40%" class=3D=
"unittests-data">testSearch</td><td width=3D"40%" class=3D"unittests-data">=
org.springframework.apptests.jpetstore.AllTests</td></tr><tr class=3D"unitt=
ests-oddrow"><td class=3D"unittests-data"> failure =
</td><td width=3D"40%" class=3D"unittests-data">testHelpPage</td><td widt=
h=3D"40%" class=3D"unittests-data">org.springframework.apptests.jpetstore.A=
llTests</td></tr><tr><td class=3D"unittests-data"> failure =
</td><td width=3D"40%" class=3D"unittests-data">testPurchase</td>=
<td width=3D"40%" class=3D"unittests-data">org.springframework.apptests.jpe=
tstore.AllTests</td></tr><tr class=3D"unittests-oddrow"><td class=3D"unitte=
sts-data"> failure </td><td width=3D"40%" class=
=3D"unittests-data">testSearch</td><td width=3D"40%" class=3D"unittests-dat=
a">org.springframework.apptests.jpetstore.AllTests</td></tr></table></td></=
tr><tr></tr><tr><td colspan=3D"2"> </td></tr><tr><td colspan=3D"4" cla=
ss=3D"unittests-sectionheader"> Unit Test Error De=
tails: (6) </td></tr><tr><td class=3D"unittests-data" c=
olspan=3D"2"> Test: testHelpPage</td></tr><tr><td class=
=3D"unittests-data" colspan=3D"2"> Class: org.springfra=
mework.apptests.jpetstore.AllTests</td></tr><tr><td class=3D"unittests-data=
" colspan=3D"2"> Type: junit.framework.AssertionFailedError<=
/td></tr><tr><td class=3D"unittests-data" colspan=3D"2"> Mes=
sage: Exception: com.meterware.httpunit.HttpInternalErrorException: Error o=
n HTTP request: 500 Internal Error [http://localhost:13084/jpetstore/shop/h=
elp.do?param=3Dfreemarker]</td></tr><tr><td class=3D"unittests-failure" col=
span=3D"2"><pre>junit.framework.AssertionFailedError: Exception: com.meterw=
are.httpunit.HttpInternalErrorException: Error on HTTP request: 500 Interna=
l Error [http://localhost:13084/jpetstore/shop/help.do?param=3Dfreemarker]<=
br>=09at org.springframework.apptests.jpetstore.AllTests.testHelpPage(Unkno=
wn Source)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Met=
hod)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces=
sorImpl.java:39)<br>=09at sun.reflect.DelegatingMethodAccessorImpl.invoke(D=
elegatingMethodAccessorImpl.java:25)<br>=09at java.lang.Thread.run(Thread.j=
ava:534)<br></pre></td></tr><tr><td class=3D"unittests-data" colspan=3D"2">=
Test: testPurchase</td></tr><tr><td class=3D"unittests=
-data" colspan=3D"2"> Class: org.springframework.apptes=
ts.jpetstore.AllTests</td></tr><tr><td class=3D"unittests-data" colspan=3D"=
2"> Type: junit.framework.AssertionFailedError</td></tr><tr>=
<td class=3D"unittests-data" colspan=3D"2"> Message: Excepti=
on: com.meterware.httpunit.HttpInternalErrorException: Error on HTTP reques=
t: 500 Internal Error [http://localhost:13084/jpetstore/shop/index.do]</td>=
</tr><tr><td class=3D"unittests-failure" colspan=3D"2"><pre>junit.framework=
.AssertionFailedError: Exception: com.meterware.httpunit.HttpInternalErrorE=
xception: Error on HTTP request: 500 Internal Error [http://localhost:13084=
/jpetstore/shop/index.do]<br>=09at org.springframework.apptests.jpetstore.A=
llTests.testPurchase(Unknown Source)<br>=09at sun.reflect.NativeMethodAcces=
sorImpl.invoke0(Native Method)<br>=09at sun.reflect.NativeMethodAccessorImp=
l.invoke(NativeMethodAccessorImpl.java:39)<br>=09at sun.reflect.DelegatingM=
ethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)<br>=09at jav=
a.lang.Thread.run(Thread.java:534)<br></pre></td></tr><tr><td class=3D"unit=
tests-data" colspan=3D"2"> Test: testSearch</td></tr><t=
r><td class=3D"unittests-data" colspan=3D"2"> Class: or=
g.springframework.apptests.jpetstore.AllTests</td></tr><tr><td class=3D"uni=
ttests-data" colspan=3D"2"> Type: junit.framework.AssertionF=
ailedError</td></tr><tr><td class=3D"unittests-data" colspan=3D"2"> =
Message: Exception: com.meterware.httpunit.HttpInternalErrorExcepti=
on: Error on HTTP request: 500 Internal Error [http://localhost:13084/jpets=
tore/shop/index.do]</td></tr><tr><td class=3D"unittests-failure" colspan=3D=
"2"><pre>junit.framework.AssertionFailedError: Exception: com.meterware.htt=
punit.HttpInternalErrorException: Error on HTTP request: 500 Internal Error=
[http://localhost:13084/jpetstore/shop/index.do]<br>=09at org.springframew=
ork.apptests.jpetstore.AllTests.testSearch(Unknown Source)<br>=09at sun.ref=
lect.NativeMethodAccessorImpl.invoke0(Native Method)<br>=09at sun.reflect.N=
ativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)<br>=09at s=
un.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl=
.java:25)<br>=09at java.lang.Thread.run(Thread.java:534)<br></pre></td></tr=
><tr><td class=3D"unittests-data" colspan=3D"2"> Test: =
testHelpPage</td></tr><tr><td class=3D"unittests-data" colspan=3D"2"> =
Class: org.springframework.apptests.jpetstore.AllTests</td><=
/tr><tr><td class=3D"unittests-data" colspan=3D"2"> Type: ju=
nit.framework.AssertionFailedError</td></tr><tr><td class=3D"unittests-data=
" colspan=3D"2"> Message: Exception: com.meterware.httpunit.=
HttpInternalErrorException: Error on HTTP request: 500 Internal Error [http=
://localhost:13084/jpetstore/shop/help.do?param=3Dfreemarker]</td></tr><tr>=
<td class=3D"unittests-failure" colspan=3D"2"><pre>junit.framework.Assertio=
nFailedError: Exception: com.meterware.httpunit.HttpInternalErrorException:=
Error on HTTP request: 500 Internal Error [http://localhost:13084/jpetstor=
e/shop/help.do?param=3Dfreemarker]<br>=09at org.springframework.apptests.jp=
etstore.AllTests.testHelpPage(Unknown Source)<br>=09at sun.reflect.NativeMe=
thodAccessorImpl.invoke0(Native Method)<br>=09at sun.reflect.NativeMethodAc=
cessorImpl.invoke(NativeMethodAccessorImpl.java:39)<br>=09at sun.reflect.De=
legatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)<br>=
=09at java.lang.Thread.run(Thread.java:534)<br></pre></td></tr><tr><td clas=
s=3D"unittests-data" colspan=3D"2"> Test: testPurchase<=
/td></tr><tr><td class=3D"unittests-data" colspan=3D"2"> Cla=
ss: org.springframework.apptests.jpetstore.AllTests</td></tr><tr><td c=
lass=3D"unittests-data" colspan=3D"2"> Type: junit.framework=
.AssertionFailedError</td></tr><tr><td class=3D"unittests-data" colspan=3D"=
2"> Message: Exception: com.meterware.httpunit.HttpInternalE=
rrorException: Error on HTTP request: 500 Internal Error [http://localhost:=
13084/jpetstore/shop/index.do]</td></tr><tr><td class=3D"unittests-failure"=
colspan=3D"2"><pre>junit.framework.AssertionFailedError: Exception: com.me=
terware.httpunit.HttpInternalErrorException: Error on HTTP request: 500 Int=
ernal Error [http://localhost:13084/jpetstore/shop/index.do]<br>=09at org.s=
pringframework.apptests.jpetstore.AllTests.testPurchase(Unknown Source)<br>=
=09at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br>=09at =
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3=
9)<br>=09at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMetho=
dAccessorImpl.java:25)<br>=09at java.lang.Thread.run(Thread.java:534)<br></=
pre></td></tr><tr><td class=3D"unittests-data" colspan=3D"2"> =
Test: testSearch</td></tr><tr><td class=3D"unittests-data" colspan=
=3D"2"> Class: org.springframework.apptests.jpetstore.A=
llTests</td></tr><tr><td class=3D"unittests-data" colspan=3D"2"> =
Type: junit.framework.AssertionFailedError</td></tr><tr><td class=3D"u=
nittests-data" colspan=3D"2"> Message: Exception: com.meterw=
are.httpunit.HttpInternalErrorException: Error on HTTP request: 500 Interna=
l Error [http://localhost:13084/jpetstore/shop/index.do]</td></tr><tr><td c=
lass=3D"unittests-failure" colspan=3D"2"><pre>junit.framework.AssertionFail=
edError: Exception: com.meterware.httpunit.HttpInternalErrorException: Erro=
r on HTTP request: 500 Internal Error [http://localhost:13084/jpetstore/sho=
p/index.do]<br>=09at org.springframework.apptests.jpetstore.AllTests.testSe=
arch(Unknown Source)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke0(=
Native Method)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke(NativeM=
ethodAccessorImpl.java:39)<br>=09at sun.reflect.DelegatingMethodAccessorImp=
l.invoke(DelegatingMethodAccessorImpl.java:25)<br>=09at java.lang.Thread.ru=
n(Thread.java:534)<br></pre></td></tr><tr><td colspan=3D"2"> </td></tr=
></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"1" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"6" 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">k=
lr8</td><td class=3D"modifications-data">sandbox/src/org/springframework/we=
b/flow/mvc/package.html</td><td class=3D"modifications-data">JavaDoc.</td><=
/tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data">mod=
ified</td><td class=3D"modifications-data">klr8</td><td class=3D"modificati=
ons-data">sandbox/src/org/springframework/web/flow/config/package.html</td>=
<td class=3D"modifications-data">JavaDoc.</td></tr><tr class=3D"modificatio=
ns-evenrow"><td class=3D"modifications-data">modified</td><td class=3D"modi=
fications-data">klr8</td><td class=3D"modifications-data">sandbox/src/org/s=
pringframework/web/flow/package.html</td><td class=3D"modifications-data">J=
avaDoc.</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: (16) </td>=
</tr><tr><td class=3D"distributables-data">Building jar: /jteam/build2/chec=
kout/spring/spring/dist/spring-core.jar</td></tr><tr class=3D"distributable=
s-oddrow"><td class=3D"distributables-data">Building jar: /jteam/build2/che=
ckout/spring/spring/dist/spring-aop.jar</td></tr><tr><td class=3D"distribut=
ables-data">Building jar: /jteam/build2/checkout/spring/spring/dist/spring-=
context.jar</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distr=
ibutables-data">Building jar: /jteam/build2/checkout/spring/spring/dist/spr=
ing-dao.jar</td></tr><tr><td class=3D"distributables-data">Building jar: /j=
team/build2/checkout/spring/spring/dist/spring-orm.jar</td></tr><tr class=
=3D"distributables-oddrow"><td class=3D"distributables-data">Building jar: =
/jteam/build2/checkout/spring/spring/dist/spring-web.jar</td></tr><tr><td c=
lass=3D"distributables-data">Building jar: /jteam/build2/checkout/spring/sp=
ring/dist/spring-webmvc.jar</td></tr><tr class=3D"distributables-oddrow"><t=
d class=3D"distributables-data">Building jar: /jteam/build2/checkout/spring=
/spring/dist/spring.jar</td></tr><tr><td class=3D"distributables-data">Buil=
ding jar: /jteam/build2/checkout/spring/spring/dist/spring-mock.jar</td></t=
r><tr class=3D"distributables-oddrow"><td class=3D"distributables-data">Bui=
lding war: /jteam/build2/checkout/spring/spring/autobuilds/apps/buildtest/d=
ist/buildtest.war</td></tr><tr><td class=3D"distributables-data">Building w=
ar: /jteam/build2/checkout/spring/spring/autobuilds/apps/buildtest/dist/bui=
ldtest.war</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distri=
butables-data">Building war: /jteam/build2/checkout/spring/spring/autobuild=
s/apps/buildtest/dist/buildtest.war</td></tr><tr><td class=3D"distributable=
s-data">Building jar: /jteam/build2/checkout/spring/spring/autobuilds/apps/=
jpetstore/war/WEB-INF/lib/jpetstore.jar</td></tr><tr class=3D"distributable=
s-oddrow"><td class=3D"distributables-data">Building war: /jteam/build2/che=
ckout/spring/spring/autobuilds/apps/jpetstore/dist/jpetstore.war</td></tr><=
tr><td class=3D"distributables-data">Building jar: /jteam/build2/checkout/s=
pring/spring/autobuilds/apps/jpetstore/war/WEB-INF/lib/jpetstore.jar</td></=
tr><tr class=3D"distributables-oddrow"><td class=3D"distributables-data">Bu=
ilding war: /jteam/build2/checkout/spring/spring/autobuilds/apps/jpetstore/=
dist/jpetstore.war</td></tr></table>
</body></html> |
|
From: Rob B. <cro...@ya...> - 2005-03-05 00:34:53
|
I thought I heard somewhere a while ago the Spring portlet support would be in 1.2? Later Rob --- Juergen Hoeller <ju...@in...> wrote: > As I said, a subproject is just under consideration. > The alternative is to > release the portlet support as part of the core > Spring 1.3 distribution. The > rationale of factoring out subprojects is to let the > core concentrate on its > current scope and not introduce completely new areas > of functionality. A > secondary goal is to limit the size of spring.jar. > > The current core web support and web MVC framework > is used by the portlet > support underneath, for example to render views (at > least that was the case > last year). So Spring Portlet depends on Spring core > web (even core web > MVC), but not the other way round: a case for core > web MVC staying part of > the core distribution, but Portlet support > (optionally) becoming a separate > subproject. > > Note that Spring's core web support is of interest > to many people: not only > to web application people, but also to rich client > developers accessing > HTTP-based remote services (running in a Servlet > container). Portlet support > is more specific and has a narrower target audience. > > A further advantage of a separate subproject is that > it can evolve more > easily. Specific sample applications, tutorials, > tools etc can be added > without having to worry about scope or size of the > core Spring distribution. > > Anyway, this has not been decided yet and does not > have to be decided right > now. It's gonna become an important topic after the > Spring 1.2 release, > though. > > Juergen > > > > -----Original Message----- > From: > spr...@li... > [mailto:spr...@li...]On > Behalf > Of Jean-Pol Landrain > Sent: Friday, March 04, 2005 7:29 PM > To: spr...@li... > Subject: Re: [Springframework-developer] Portlet > Form Controllers > > > I quite agree with Rob. Except, of course, if you > plan to create a > subproject for Spring MVC too. This would allow a > Spring "à la carte". > This would keep the framework light, but would > perhaps be a bit confusing to > the users. Perhaps a "plugin" functionnality would > be nice if the number of > projects grows : you would have a core Spring and be > able to plug in, for > example by using a dedicated XML file, the other > sub-projects you want to > use. That's just an idea. > > Cheers, > Jean-Pol. > > ----- Original Message ----- > From: "Rob Butler" <cro...@ya...> > To: > <spr...@li...> > Sent: Friday, March 04, 2005 7:01 PM > Subject: Re: [Springframework-developer] Portlet > Form Controllers > > > > Why would you have a separate sub-project for the > > portlet support in Spring? That would be like > having > > a separate sub-project for the web MVC stuff, and > a > > separate sub-project for the DAO related stuff, > and > > another one for AOP, etc. > > > > Later > > Rob > > --- Juergen Hoeller <ju...@in...> > wrote: > > > >> Sounds like good stuff :-) > >> > >> On this occasion: Let's discuss the road to an > >> official release of the > >> Portlet support. We consider releasing the > Portlet > >> support as an official > >> subproject, i.e. as a separate distribution and > with > >> a separate CVS module > >> (or even separate CVS repository). The > association > >> would be similar to the > >> just-announced Spring subproject status of Acegi > >> Security, and the already > >> established status of Spring RCP. > >> > >> Very importantly, the portlet subproject needs a > >> dedicated developer team. > >> Any volunteers? :-) > >> > >> Juergen > >> > >> > >> -----Original Message----- > >> From: > >> > > > spr...@li... > >> > > > [mailto:spr...@li...]On > >> Behalf > >> Of John Lewis > >> Sent: Thursday, March 03, 2005 6:53 PM > >> To: > spr...@li... > >> Subject: [Springframework-developer] Portlet Form > >> Controllers > >> > >> > >> We've been working on porting a fairly complex > >> enterprise application > >> from the Spring Servlet MVC framework to the > Spring > >> Portlet MVC > >> framework. As Nick Lothian and Rainer Schmitz > >> discovered, the Form > >> Controller hierarchy is difficult to port over > from > >> the Servlet area to > >> the Portlet area because of the two-phase nature > of > >> portlet requests. > >> Since we were porting a large number of existing > >> controllers descended > >> from AbstractController, AbstractFormController, > or > >> SimpleFormController, it was critical to that all > >> the former > >> functionality of these parent be present and that > >> our logic work the > >> same as before. > >> > >> Nick Lothian's version of > >> SimplePortletFormController gave us a good > >> starting point and helped us understand a lot of > the > >> issues with portlet > >> development in general and with Spring portlets > in > >> particular. However, > >> a lot of our controllers manage database content, > so > >> we needed proper > >> separation between the action and render phase of > >> the request, which > >> this controller did not give us. > >> > >> Rainer Schmitz's work went much further and > provided > >> the traditional > >> hierarchy of controllers and further demonstrated > >> the issues with > >> separating out the two phases of the portlet > >> request. However, these > >> still did not give us the complete control that > we > >> needed. We > >> especially needed a version of > SimpleFormController > >> that could handle > >> the separation of the action logic from the > render > >> logic. > >> > >> Over the past few months we have developed a new > set > >> of the > >> AbstractController, BaseCommandController, > >> AbstractFormController, and > >> SimpleFormController classes that we think > >> rigorously address all the > >> issues with portlet development and that have > >> allowed us to port over > >> existing servlet controllers with relative ease. > >> > >> We've included a portlet version of > >> WebContentGenerator to give the > >> controller classes their proper ancestry and > provide > >> control over things > >> like content caching and access to the web > >> application context and to > >> centralized logging. > >> > >> We've also create a new set of the binding > classes > >> (PortletRequestDataBinder, > >> PortletRequestParameterPropertyValues and > >> PortletRequestBindingException) that support > special > >> field markers, > >> correct problems with form elements such as radio > >> buttons and > >> checkboxes, and handle redisplay of invalid > submits > >> of non-string > >> parameters properly. > >> > >> All of the classes are fully documented, > including > >> workflow descriptions > >> in the controllers that cover the special nature > of > >> portlet development. > >> > >> Our hope is that these classes can handle the > needs > >> of everyone working > >> with form controllers in Spring portlets and that > >> these can be merged > >> into the sandbox source code. > >> > >> The classes are posted in a zip file on the > Spring > >> Portlet Wiki page at: > >> > > > http://opensource.atlassian.com/confluence/spring/display/JSR168/ > >> > >> The link to the file is (sorry for the long > link): > >> > > > http://opensource.atlassian.com/confluence/spring/download/attachments/10/sp > >> ring-portlet-controllers.zip > >> > >> Please send me any questions or comments you may > >> have about these > >> classes. We are eager to support their adoption > in > >> the Spring Portlet > >> community. > >> > >> John Lewis > >> jl...@ar... > >> > >> > >> > >> > > > ------------------------------------------------------- > >> SF email is sponsored by - The IT Product Guide > >> Read honest & candid reviews on hundreds of IT > >> Products from real users. > >> Discover which products truly live up to the > hype. > >> Start reading now. > >> > > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >> _______________________________________________ > >> Springframework-developer mailing list > >> Spr...@li... > >> > > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > >> > >> > >> > >> > > > ------------------------------------------------------- > >> SF email is sponsored by - The IT Product Guide > >> Read honest & candid reviews on hundreds of IT > >> Products from real users. > >> Discover which products truly live up to the > hype. > >> Start reading now. > >> > > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >> _______________________________________________ > >> Springframework-developer mailing list > >> Spr...@li... > >> > > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > >> > > > > > > > > > > > > __________________________________ > > Celebrate Yahoo!'s 10th Birthday! > > Yahoo! Netrospective: 100 Moments of the Web > > http://birthday.yahoo.com/netrospective/ > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT > Products from real users. > > Discover which products truly live up to the hype. > Start reading now. > > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the hype. > Start reading now. > http://ads.osdn.com/?ad_ide95&alloc_id396&op=ick > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the hype. > Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ |
|
From: Juergen H. <ju...@in...> - 2005-03-04 22:54:00
|
We don't need to vote right now; we're just gathering opinions :-) The decision will also depend on the final size of the Portlet support. If it turns out to be too small for a separate subproject, including it in the core distribution might be the only feasible way to go. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Ken Krebs Sent: Friday, March 04, 2005 11:47 PM To: spr...@li... Subject: Re: [Springframework-developer] Portlet Form Controllers +1 for subproject status. It makes sense to me to let them evolve in a more loosely coupled way, especially as Juergen points out given the small target audience for portlets. Juergen Hoeller wrote: >As I said, a subproject is just under consideration. The alternative is to >release the portlet support as part of the core Spring 1.3 distribution. The >rationale of factoring out subprojects is to let the core concentrate on its >current scope and not introduce completely new areas of functionality. A >secondary goal is to limit the size of spring.jar. > >The current core web support and web MVC framework is used by the portlet >support underneath, for example to render views (at least that was the case >last year). So Spring Portlet depends on Spring core web (even core web >MVC), but not the other way round: a case for core web MVC staying part of >the core distribution, but Portlet support (optionally) becoming a separate >subproject. > >Note that Spring's core web support is of interest to many people: not only >to web application people, but also to rich client developers accessing >HTTP-based remote services (running in a Servlet container). Portlet support >is more specific and has a narrower target audience. > >A further advantage of a separate subproject is that it can evolve more >easily. Specific sample applications, tutorials, tools etc can be added >without having to worry about scope or size of the core Spring distribution. > >Anyway, this has not been decided yet and does not have to be decided right >now. It's gonna become an important topic after the Spring 1.2 release, >though. > >Juergen > > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of Jean-Pol Landrain >Sent: Friday, March 04, 2005 7:29 PM >To: spr...@li... >Subject: Re: [Springframework-developer] Portlet Form Controllers > > >I quite agree with Rob. Except, of course, if you plan to create a >subproject for Spring MVC too. This would allow a Spring "à la carte". >This would keep the framework light, but would perhaps be a bit confusing to >the users. Perhaps a "plugin" functionnality would be nice if the number of >projects grows : you would have a core Spring and be able to plug in, for >example by using a dedicated XML file, the other sub-projects you want to >use. That's just an idea. > >Cheers, >Jean-Pol. > >----- Original Message ----- >From: "Rob Butler" <cro...@ya...> >To: <spr...@li...> >Sent: Friday, March 04, 2005 7:01 PM >Subject: Re: [Springframework-developer] Portlet Form Controllers > > > > >>Why would you have a separate sub-project for the >>portlet support in Spring? That would be like having >>a separate sub-project for the web MVC stuff, and a >>separate sub-project for the DAO related stuff, and >>another one for AOP, etc. >> >>Later >>Rob >>--- Juergen Hoeller <ju...@in...> wrote: >> >> >> >>>Sounds like good stuff :-) >>> >>>On this occasion: Let's discuss the road to an >>>official release of the >>>Portlet support. We consider releasing the Portlet >>>support as an official >>>subproject, i.e. as a separate distribution and with >>>a separate CVS module >>>(or even separate CVS repository). The association >>>would be similar to the >>>just-announced Spring subproject status of Acegi >>>Security, and the already >>>established status of Spring RCP. >>> >>>Very importantly, the portlet subproject needs a >>>dedicated developer team. >>>Any volunteers? :-) >>> >>>Juergen >>> >>> >>>-----Original Message----- >>>From: >>> >>> >>> >>spr...@li... >> >> >>[mailto:spr...@li...]On >> >> >>>Behalf >>>Of John Lewis >>>Sent: Thursday, March 03, 2005 6:53 PM >>>To: spr...@li... >>>Subject: [Springframework-developer] Portlet Form >>>Controllers >>> >>> >>>We've been working on porting a fairly complex >>>enterprise application >>>from the Spring Servlet MVC framework to the Spring >>>Portlet MVC >>>framework. As Nick Lothian and Rainer Schmitz >>>discovered, the Form >>>Controller hierarchy is difficult to port over from >>>the Servlet area to >>>the Portlet area because of the two-phase nature of >>>portlet requests. >>>Since we were porting a large number of existing >>>controllers descended >>>from AbstractController, AbstractFormController, or >>>SimpleFormController, it was critical to that all >>>the former >>>functionality of these parent be present and that >>>our logic work the >>>same as before. >>> >>>Nick Lothian's version of >>>SimplePortletFormController gave us a good >>>starting point and helped us understand a lot of the >>>issues with portlet >>>development in general and with Spring portlets in >>>particular. However, >>>a lot of our controllers manage database content, so >>>we needed proper >>>separation between the action and render phase of >>>the request, which >>>this controller did not give us. >>> >>>Rainer Schmitz's work went much further and provided >>>the traditional >>>hierarchy of controllers and further demonstrated >>>the issues with >>>separating out the two phases of the portlet >>>request. However, these >>>still did not give us the complete control that we >>>needed. We >>>especially needed a version of SimpleFormController >>>that could handle >>>the separation of the action logic from the render >>>logic. >>> >>>Over the past few months we have developed a new set >>>of the >>>AbstractController, BaseCommandController, >>>AbstractFormController, and >>>SimpleFormController classes that we think >>>rigorously address all the >>>issues with portlet development and that have >>>allowed us to port over >>>existing servlet controllers with relative ease. >>> >>>We've included a portlet version of >>>WebContentGenerator to give the >>>controller classes their proper ancestry and provide >>>control over things >>>like content caching and access to the web >>>application context and to >>>centralized logging. >>> >>>We've also create a new set of the binding classes >>>(PortletRequestDataBinder, >>>PortletRequestParameterPropertyValues and >>>PortletRequestBindingException) that support special >>>field markers, >>>correct problems with form elements such as radio >>>buttons and >>>checkboxes, and handle redisplay of invalid submits >>>of non-string >>>parameters properly. >>> >>>All of the classes are fully documented, including >>>workflow descriptions >>>in the controllers that cover the special nature of >>>portlet development. >>> >>>Our hope is that these classes can handle the needs >>>of everyone working >>>with form controllers in Spring portlets and that >>>these can be merged >>>into the sandbox source code. >>> >>>The classes are posted in a zip file on the Spring >>>Portlet Wiki page at: >>> >>> >>> >>http://opensource.atlassian.com/confluence/spring/display/JSR168/ >> >> >>>The link to the file is (sorry for the long link): >>> >>> >>> >http://opensource.atlassian.com/confluence/spring/download/attachments/10/s p > > >>>ring-portlet-controllers.zip >>> >>>Please send me any questions or comments you may >>>have about these >>>classes. We are eager to support their adoption in >>>the Spring Portlet >>>community. >>> >>>John Lewis >>>jl...@ar... >>> >>> >>> >>> >>> >>> ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=ick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Ken K. <kk...@kk...> - 2005-03-04 22:47:34
|
+1 for subproject status. It makes sense to me to let them evolve in a more loosely coupled way,=20 especially as Juergen points out given the small target audience for=20 portlets. Juergen Hoeller wrote: >As I said, a subproject is just under consideration. The alternative is = to >release the portlet support as part of the core Spring 1.3 distribution.= The >rationale of factoring out subprojects is to let the core concentrate on= its >current scope and not introduce completely new areas of functionality. A >secondary goal is to limit the size of spring.jar. > >The current core web support and web MVC framework is used by the portle= t >support underneath, for example to render views (at least that was the c= ase >last year). So Spring Portlet depends on Spring core web (even core web >MVC), but not the other way round: a case for core web MVC staying part = of >the core distribution, but Portlet support (optionally) becoming a separ= ate >subproject. > >Note that Spring's core web support is of interest to many people: not o= nly >to web application people, but also to rich client developers accessing >HTTP-based remote services (running in a Servlet container). Portlet sup= port >is more specific and has a narrower target audience. > >A further advantage of a separate subproject is that it can evolve more >easily. Specific sample applications, tutorials, tools etc can be added >without having to worry about scope or size of the core Spring distribut= ion. > >Anyway, this has not been decided yet and does not have to be decided ri= ght >now. It's gonna become an important topic after the Spring 1.2 release, >though. > >Juergen > > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of Jean-Pol Landrain >Sent: Friday, March 04, 2005 7:29 PM >To: spr...@li... >Subject: Re: [Springframework-developer] Portlet Form Controllers > > >I quite agree with Rob. Except, of course, if you plan to create a >subproject for Spring MVC too. This would allow a Spring "=E0 la carte". >This would keep the framework light, but would perhaps be a bit confusin= g to >the users. Perhaps a "plugin" functionnality would be nice if the number= of >projects grows : you would have a core Spring and be able to plug in, fo= r >example by using a dedicated XML file, the other sub-projects you want t= o >use. That's just an idea. > >Cheers, >Jean-Pol. > >----- Original Message ----- >From: "Rob Butler" <cro...@ya...> >To: <spr...@li...> >Sent: Friday, March 04, 2005 7:01 PM >Subject: Re: [Springframework-developer] Portlet Form Controllers > > > =20 > >>Why would you have a separate sub-project for the >>portlet support in Spring? That would be like having >>a separate sub-project for the web MVC stuff, and a >>separate sub-project for the DAO related stuff, and >>another one for AOP, etc. >> >>Later >>Rob >>--- Juergen Hoeller <ju...@in...> wrote: >> >> =20 >> >>>Sounds like good stuff :-) >>> >>>On this occasion: Let's discuss the road to an >>>official release of the >>>Portlet support. We consider releasing the Portlet >>>support as an official >>>subproject, i.e. as a separate distribution and with >>>a separate CVS module >>>(or even separate CVS repository). The association >>>would be similar to the >>>just-announced Spring subproject status of Acegi >>>Security, and the already >>>established status of Spring RCP. >>> >>>Very importantly, the portlet subproject needs a >>>dedicated developer team. >>>Any volunteers? :-) >>> >>>Juergen >>> >>> >>>-----Original Message----- >>>From: >>> >>> =20 >>> >>spr...@li... >> =20 >> >>[mailto:spr...@li...]On >> =20 >> >>>Behalf >>>Of John Lewis >>>Sent: Thursday, March 03, 2005 6:53 PM >>>To: spr...@li... >>>Subject: [Springframework-developer] Portlet Form >>>Controllers >>> >>> >>>We've been working on porting a fairly complex >>>enterprise application >>>from the Spring Servlet MVC framework to the Spring >>>Portlet MVC >>>framework. As Nick Lothian and Rainer Schmitz >>>discovered, the Form >>>Controller hierarchy is difficult to port over from >>>the Servlet area to >>>the Portlet area because of the two-phase nature of >>>portlet requests. >>>Since we were porting a large number of existing >>>controllers descended >>>from AbstractController, AbstractFormController, or >>>SimpleFormController, it was critical to that all >>>the former >>>functionality of these parent be present and that >>>our logic work the >>>same as before. >>> >>>Nick Lothian's version of >>>SimplePortletFormController gave us a good >>>starting point and helped us understand a lot of the >>>issues with portlet >>>development in general and with Spring portlets in >>>particular. However, >>>a lot of our controllers manage database content, so >>>we needed proper >>>separation between the action and render phase of >>>the request, which >>>this controller did not give us. >>> >>>Rainer Schmitz's work went much further and provided >>>the traditional >>>hierarchy of controllers and further demonstrated >>>the issues with >>>separating out the two phases of the portlet >>>request. However, these >>>still did not give us the complete control that we >>>needed. We >>>especially needed a version of SimpleFormController >>>that could handle >>>the separation of the action logic from the render >>>logic. >>> >>>Over the past few months we have developed a new set >>>of the >>>AbstractController, BaseCommandController, >>>AbstractFormController, and >>>SimpleFormController classes that we think >>>rigorously address all the >>>issues with portlet development and that have >>>allowed us to port over >>>existing servlet controllers with relative ease. >>> >>>We've included a portlet version of >>>WebContentGenerator to give the >>>controller classes their proper ancestry and provide >>>control over things >>>like content caching and access to the web >>>application context and to >>>centralized logging. >>> >>>We've also create a new set of the binding classes >>>(PortletRequestDataBinder, >>>PortletRequestParameterPropertyValues and >>>PortletRequestBindingException) that support special >>>field markers, >>>correct problems with form elements such as radio >>>buttons and >>>checkboxes, and handle redisplay of invalid submits >>>of non-string >>>parameters properly. >>> >>>All of the classes are fully documented, including >>>workflow descriptions >>>in the controllers that cover the special nature of >>>portlet development. >>> >>>Our hope is that these classes can handle the needs >>>of everyone working >>>with form controllers in Spring portlets and that >>>these can be merged >>>into the sandbox source code. >>> >>>The classes are posted in a zip file on the Spring >>>Portlet Wiki page at: >>> >>> =20 >>> >>http://opensource.atlassian.com/confluence/spring/display/JSR168/ >> =20 >> >>>The link to the file is (sorry for the long link): >>> >>> =20 >>> >http://opensource.atlassian.com/confluence/spring/download/attachments/1= 0/sp > =20 > >>>ring-portlet-controllers.zip >>> >>>Please send me any questions or comments you may >>>have about these >>>classes. We are eager to support their adoption in >>>the Spring Portlet >>>community. >>> >>>John Lewis >>>jl...@ar... >>> >>> >>> >>> >>> =20 >>> |
|
From: Matt S. <sga...@us...> - 2005-03-04 19:33:32
|
Sounds reasonable to me. You should probably add an enhancement request
to JIRA.
Matt
Andy Depue wrote:
> Well, actually, here is what I was thinking. Say that I pull a resource from
> a file or classpath (file: or classpath: or even just a relative path).
> Then, sure, just figure out the mime type based on file extension when I call
> "getMimeType" (or whatever) against the Resource. That at least saves me the
> trouble of parsing the filename or calling into the activation framework.
> BUT, if I pass in a URL to a resource where the mime type is handled
> independently of the filename (such as a "http:" URL, where the server will
> return a type header), then return the specific mime type that was returned
> by the server. See URL.openConnection().getContentType(). A simple
> algorithm could be:
>
> getMimeType() {
> return URL.openConnection().getContentType() if not null,
> otherwise parse filename/use activation framework.
> }
>
> - Andy
>
> On Friday 04 March 2005 07:01 am, Matt Sgarlata wrote:
>
>>OK, I see what you're getting at now. The problem is, how do you want
>>Spring to figure out the mime type if it's not based on file extension?
>> By dynamically inspecting the contents of the file at runtime? I know
>>that's possible because IE does it, but that seems like it would be a
>>pain to implement. Is there some other approach you could take, like
>>storing the mime type information external to the file itself?
>>
>>Matt
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
|
|
From: Juergen H. <ju...@in...> - 2005-03-04 19:13:33
|
As I said, a subproject is just under consideration. The alternative is to release the portlet support as part of the core Spring 1.3 distribution. The rationale of factoring out subprojects is to let the core concentrate on its current scope and not introduce completely new areas of functionality. A secondary goal is to limit the size of spring.jar. The current core web support and web MVC framework is used by the portlet support underneath, for example to render views (at least that was the case last year). So Spring Portlet depends on Spring core web (even core web MVC), but not the other way round: a case for core web MVC staying part of the core distribution, but Portlet support (optionally) becoming a separate subproject. Note that Spring's core web support is of interest to many people: not only to web application people, but also to rich client developers accessing HTTP-based remote services (running in a Servlet container). Portlet support is more specific and has a narrower target audience. A further advantage of a separate subproject is that it can evolve more easily. Specific sample applications, tutorials, tools etc can be added without having to worry about scope or size of the core Spring distribution. Anyway, this has not been decided yet and does not have to be decided right now. It's gonna become an important topic after the Spring 1.2 release, though. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Jean-Pol Landrain Sent: Friday, March 04, 2005 7:29 PM To: spr...@li... Subject: Re: [Springframework-developer] Portlet Form Controllers I quite agree with Rob. Except, of course, if you plan to create a subproject for Spring MVC too. This would allow a Spring "à la carte". This would keep the framework light, but would perhaps be a bit confusing to the users. Perhaps a "plugin" functionnality would be nice if the number of projects grows : you would have a core Spring and be able to plug in, for example by using a dedicated XML file, the other sub-projects you want to use. That's just an idea. Cheers, Jean-Pol. ----- Original Message ----- From: "Rob Butler" <cro...@ya...> To: <spr...@li...> Sent: Friday, March 04, 2005 7:01 PM Subject: Re: [Springframework-developer] Portlet Form Controllers > Why would you have a separate sub-project for the > portlet support in Spring? That would be like having > a separate sub-project for the web MVC stuff, and a > separate sub-project for the DAO related stuff, and > another one for AOP, etc. > > Later > Rob > --- Juergen Hoeller <ju...@in...> wrote: > >> Sounds like good stuff :-) >> >> On this occasion: Let's discuss the road to an >> official release of the >> Portlet support. We consider releasing the Portlet >> support as an official >> subproject, i.e. as a separate distribution and with >> a separate CVS module >> (or even separate CVS repository). The association >> would be similar to the >> just-announced Spring subproject status of Acegi >> Security, and the already >> established status of Spring RCP. >> >> Very importantly, the portlet subproject needs a >> dedicated developer team. >> Any volunteers? :-) >> >> Juergen >> >> >> -----Original Message----- >> From: >> > spr...@li... >> > [mailto:spr...@li...]On >> Behalf >> Of John Lewis >> Sent: Thursday, March 03, 2005 6:53 PM >> To: spr...@li... >> Subject: [Springframework-developer] Portlet Form >> Controllers >> >> >> We've been working on porting a fairly complex >> enterprise application >> from the Spring Servlet MVC framework to the Spring >> Portlet MVC >> framework. As Nick Lothian and Rainer Schmitz >> discovered, the Form >> Controller hierarchy is difficult to port over from >> the Servlet area to >> the Portlet area because of the two-phase nature of >> portlet requests. >> Since we were porting a large number of existing >> controllers descended >> from AbstractController, AbstractFormController, or >> SimpleFormController, it was critical to that all >> the former >> functionality of these parent be present and that >> our logic work the >> same as before. >> >> Nick Lothian's version of >> SimplePortletFormController gave us a good >> starting point and helped us understand a lot of the >> issues with portlet >> development in general and with Spring portlets in >> particular. However, >> a lot of our controllers manage database content, so >> we needed proper >> separation between the action and render phase of >> the request, which >> this controller did not give us. >> >> Rainer Schmitz's work went much further and provided >> the traditional >> hierarchy of controllers and further demonstrated >> the issues with >> separating out the two phases of the portlet >> request. However, these >> still did not give us the complete control that we >> needed. We >> especially needed a version of SimpleFormController >> that could handle >> the separation of the action logic from the render >> logic. >> >> Over the past few months we have developed a new set >> of the >> AbstractController, BaseCommandController, >> AbstractFormController, and >> SimpleFormController classes that we think >> rigorously address all the >> issues with portlet development and that have >> allowed us to port over >> existing servlet controllers with relative ease. >> >> We've included a portlet version of >> WebContentGenerator to give the >> controller classes their proper ancestry and provide >> control over things >> like content caching and access to the web >> application context and to >> centralized logging. >> >> We've also create a new set of the binding classes >> (PortletRequestDataBinder, >> PortletRequestParameterPropertyValues and >> PortletRequestBindingException) that support special >> field markers, >> correct problems with form elements such as radio >> buttons and >> checkboxes, and handle redisplay of invalid submits >> of non-string >> parameters properly. >> >> All of the classes are fully documented, including >> workflow descriptions >> in the controllers that cover the special nature of >> portlet development. >> >> Our hope is that these classes can handle the needs >> of everyone working >> with form controllers in Spring portlets and that >> these can be merged >> into the sandbox source code. >> >> The classes are posted in a zip file on the Spring >> Portlet Wiki page at: >> > http://opensource.atlassian.com/confluence/spring/display/JSR168/ >> >> The link to the file is (sorry for the long link): >> > http://opensource.atlassian.com/confluence/spring/download/attachments/10/sp >> ring-portlet-controllers.zip >> >> Please send me any questions or comments you may >> have about these >> classes. We are eager to support their adoption in >> the Spring Portlet >> community. >> >> John Lewis >> jl...@ar... >> >> >> >> > ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT >> Products from real users. >> Discover which products truly live up to the hype. >> Start reading now. >> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> > https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >> > ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT >> Products from real users. >> Discover which products truly live up to the hype. >> Start reading now. >> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> > https://lists.sourceforge.net/lists/listinfo/springframework-developer >> > > > > > > __________________________________ > Celebrate Yahoo!'s 10th Birthday! > Yahoo! Netrospective: 100 Moments of the Web > http://birthday.yahoo.com/netrospective/ > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=ick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Jean-Pol L. <jea...@sk...> - 2005-03-04 18:28:54
|
I quite agree with Rob. Except, of course, if you plan to create a=20 subproject for Spring MVC too. This would allow a Spring "=E0 la carte". This would keep the framework light, but would perhaps be a bit confusing= to=20 the users. Perhaps a "plugin" functionnality would be nice if the number = of=20 projects grows : you would have a core Spring and be able to plug in, for= =20 example by using a dedicated XML file, the other sub-projects you want to= =20 use. That's just an idea. Cheers, Jean-Pol. ----- Original Message -----=20 From: "Rob Butler" <cro...@ya...> To: <spr...@li...> Sent: Friday, March 04, 2005 7:01 PM Subject: Re: [Springframework-developer] Portlet Form Controllers > Why would you have a separate sub-project for the > portlet support in Spring? That would be like having > a separate sub-project for the web MVC stuff, and a > separate sub-project for the DAO related stuff, and > another one for AOP, etc. > > Later > Rob > --- Juergen Hoeller <ju...@in...> wrote: > >> Sounds like good stuff :-) >> >> On this occasion: Let's discuss the road to an >> official release of the >> Portlet support. We consider releasing the Portlet >> support as an official >> subproject, i.e. as a separate distribution and with >> a separate CVS module >> (or even separate CVS repository). The association >> would be similar to the >> just-announced Spring subproject status of Acegi >> Security, and the already >> established status of Spring RCP. >> >> Very importantly, the portlet subproject needs a >> dedicated developer team. >> Any volunteers? :-) >> >> Juergen >> >> >> -----Original Message----- >> From: >> > spr...@li... >> > [mailto:spr...@li...]On >> Behalf >> Of John Lewis >> Sent: Thursday, March 03, 2005 6:53 PM >> To: spr...@li... >> Subject: [Springframework-developer] Portlet Form >> Controllers >> >> >> We've been working on porting a fairly complex >> enterprise application >> from the Spring Servlet MVC framework to the Spring >> Portlet MVC >> framework. As Nick Lothian and Rainer Schmitz >> discovered, the Form >> Controller hierarchy is difficult to port over from >> the Servlet area to >> the Portlet area because of the two-phase nature of >> portlet requests. >> Since we were porting a large number of existing >> controllers descended >> from AbstractController, AbstractFormController, or >> SimpleFormController, it was critical to that all >> the former >> functionality of these parent be present and that >> our logic work the >> same as before. >> >> Nick Lothian's version of >> SimplePortletFormController gave us a good >> starting point and helped us understand a lot of the >> issues with portlet >> development in general and with Spring portlets in >> particular. However, >> a lot of our controllers manage database content, so >> we needed proper >> separation between the action and render phase of >> the request, which >> this controller did not give us. >> >> Rainer Schmitz's work went much further and provided >> the traditional >> hierarchy of controllers and further demonstrated >> the issues with >> separating out the two phases of the portlet >> request. However, these >> still did not give us the complete control that we >> needed. We >> especially needed a version of SimpleFormController >> that could handle >> the separation of the action logic from the render >> logic. >> >> Over the past few months we have developed a new set >> of the >> AbstractController, BaseCommandController, >> AbstractFormController, and >> SimpleFormController classes that we think >> rigorously address all the >> issues with portlet development and that have >> allowed us to port over >> existing servlet controllers with relative ease. >> >> We've included a portlet version of >> WebContentGenerator to give the >> controller classes their proper ancestry and provide >> control over things >> like content caching and access to the web >> application context and to >> centralized logging. >> >> We've also create a new set of the binding classes >> (PortletRequestDataBinder, >> PortletRequestParameterPropertyValues and >> PortletRequestBindingException) that support special >> field markers, >> correct problems with form elements such as radio >> buttons and >> checkboxes, and handle redisplay of invalid submits >> of non-string >> parameters properly. >> >> All of the classes are fully documented, including >> workflow descriptions >> in the controllers that cover the special nature of >> portlet development. >> >> Our hope is that these classes can handle the needs >> of everyone working >> with form controllers in Spring portlets and that >> these can be merged >> into the sandbox source code. >> >> The classes are posted in a zip file on the Spring >> Portlet Wiki page at: >> > http://opensource.atlassian.com/confluence/spring/display/JSR168/ >> >> The link to the file is (sorry for the long link): >> > http://opensource.atlassian.com/confluence/spring/download/attachments/= 10/sp >> ring-portlet-controllers.zip >> >> Please send me any questions or comments you may >> have about these >> classes. We are eager to support their adoption in >> the Spring Portlet >> community. >> >> John Lewis >> jl...@ar... >> >> >> >> > ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT >> Products from real users. >> Discover which products truly live up to the hype. >> Start reading now. >> > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> > https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >> > ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT >> Products from real users. >> Discover which products truly live up to the hype. >> Start reading now. >> > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> > https://lists.sourceforge.net/lists/listinfo/springframework-developer >> > > > > > > __________________________________ > Celebrate Yahoo!'s 10th Birthday! > Yahoo! Netrospective: 100 Moments of the Web > http://birthday.yahoo.com/netrospective/ > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 |
|
From: Andy D. <an...@ma...> - 2005-03-04 18:20:15
|
Well, actually, here is what I was thinking. Say that I pull a resource from
a file or classpath (file: or classpath: or even just a relative path).
Then, sure, just figure out the mime type based on file extension when I call
"getMimeType" (or whatever) against the Resource. That at least saves me the
trouble of parsing the filename or calling into the activation framework.
BUT, if I pass in a URL to a resource where the mime type is handled
independently of the filename (such as a "http:" URL, where the server will
return a type header), then return the specific mime type that was returned
by the server. See URL.openConnection().getContentType(). A simple
algorithm could be:
getMimeType() {
return URL.openConnection().getContentType() if not null,
otherwise parse filename/use activation framework.
}
- Andy
On Friday 04 March 2005 07:01 am, Matt Sgarlata wrote:
> OK, I see what you're getting at now. The problem is, how do you want
> Spring to figure out the mime type if it's not based on file extension?
> By dynamically inspecting the contents of the file at runtime? I know
> that's possible because IE does it, but that seems like it would be a
> pain to implement. Is there some other approach you could take, like
> storing the mime type information external to the file itself?
>
> Matt
|
|
From: Rob B. <cro...@ya...> - 2005-03-04 18:01:53
|
Why would you have a separate sub-project for the portlet support in Spring? That would be like having a separate sub-project for the web MVC stuff, and a separate sub-project for the DAO related stuff, and another one for AOP, etc. Later Rob --- Juergen Hoeller <ju...@in...> wrote: > Sounds like good stuff :-) > > On this occasion: Let's discuss the road to an > official release of the > Portlet support. We consider releasing the Portlet > support as an official > subproject, i.e. as a separate distribution and with > a separate CVS module > (or even separate CVS repository). The association > would be similar to the > just-announced Spring subproject status of Acegi > Security, and the already > established status of Spring RCP. > > Very importantly, the portlet subproject needs a > dedicated developer team. > Any volunteers? :-) > > Juergen > > > -----Original Message----- > From: > spr...@li... > [mailto:spr...@li...]On > Behalf > Of John Lewis > Sent: Thursday, March 03, 2005 6:53 PM > To: spr...@li... > Subject: [Springframework-developer] Portlet Form > Controllers > > > We've been working on porting a fairly complex > enterprise application > from the Spring Servlet MVC framework to the Spring > Portlet MVC > framework. As Nick Lothian and Rainer Schmitz > discovered, the Form > Controller hierarchy is difficult to port over from > the Servlet area to > the Portlet area because of the two-phase nature of > portlet requests. > Since we were porting a large number of existing > controllers descended > from AbstractController, AbstractFormController, or > SimpleFormController, it was critical to that all > the former > functionality of these parent be present and that > our logic work the > same as before. > > Nick Lothian's version of > SimplePortletFormController gave us a good > starting point and helped us understand a lot of the > issues with portlet > development in general and with Spring portlets in > particular. However, > a lot of our controllers manage database content, so > we needed proper > separation between the action and render phase of > the request, which > this controller did not give us. > > Rainer Schmitz's work went much further and provided > the traditional > hierarchy of controllers and further demonstrated > the issues with > separating out the two phases of the portlet > request. However, these > still did not give us the complete control that we > needed. We > especially needed a version of SimpleFormController > that could handle > the separation of the action logic from the render > logic. > > Over the past few months we have developed a new set > of the > AbstractController, BaseCommandController, > AbstractFormController, and > SimpleFormController classes that we think > rigorously address all the > issues with portlet development and that have > allowed us to port over > existing servlet controllers with relative ease. > > We've included a portlet version of > WebContentGenerator to give the > controller classes their proper ancestry and provide > control over things > like content caching and access to the web > application context and to > centralized logging. > > We've also create a new set of the binding classes > (PortletRequestDataBinder, > PortletRequestParameterPropertyValues and > PortletRequestBindingException) that support special > field markers, > correct problems with form elements such as radio > buttons and > checkboxes, and handle redisplay of invalid submits > of non-string > parameters properly. > > All of the classes are fully documented, including > workflow descriptions > in the controllers that cover the special nature of > portlet development. > > Our hope is that these classes can handle the needs > of everyone working > with form controllers in Spring portlets and that > these can be merged > into the sandbox source code. > > The classes are posted in a zip file on the Spring > Portlet Wiki page at: > http://opensource.atlassian.com/confluence/spring/display/JSR168/ > > The link to the file is (sorry for the long link): > http://opensource.atlassian.com/confluence/spring/download/attachments/10/sp > ring-portlet-controllers.zip > > Please send me any questions or comments you may > have about these > classes. We are eager to support their adoption in > the Spring Portlet > community. > > John Lewis > jl...@ar... > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the hype. > Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the hype. > Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ |
|
From: Juergen H. <ju...@in...> - 2005-03-04 17:41:44
|
Sounds like good stuff :-) On this occasion: Let's discuss the road to an official release of the Portlet support. We consider releasing the Portlet support as an official subproject, i.e. as a separate distribution and with a separate CVS module (or even separate CVS repository). The association would be similar to the just-announced Spring subproject status of Acegi Security, and the already established status of Spring RCP. Very importantly, the portlet subproject needs a dedicated developer team. Any volunteers? :-) Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of John Lewis Sent: Thursday, March 03, 2005 6:53 PM To: spr...@li... Subject: [Springframework-developer] Portlet Form Controllers We've been working on porting a fairly complex enterprise application from the Spring Servlet MVC framework to the Spring Portlet MVC framework. As Nick Lothian and Rainer Schmitz discovered, the Form Controller hierarchy is difficult to port over from the Servlet area to the Portlet area because of the two-phase nature of portlet requests. Since we were porting a large number of existing controllers descended from AbstractController, AbstractFormController, or SimpleFormController, it was critical to that all the former functionality of these parent be present and that our logic work the same as before. Nick Lothian's version of SimplePortletFormController gave us a good starting point and helped us understand a lot of the issues with portlet development in general and with Spring portlets in particular. However, a lot of our controllers manage database content, so we needed proper separation between the action and render phase of the request, which this controller did not give us. Rainer Schmitz's work went much further and provided the traditional hierarchy of controllers and further demonstrated the issues with separating out the two phases of the portlet request. However, these still did not give us the complete control that we needed. We especially needed a version of SimpleFormController that could handle the separation of the action logic from the render logic. Over the past few months we have developed a new set of the AbstractController, BaseCommandController, AbstractFormController, and SimpleFormController classes that we think rigorously address all the issues with portlet development and that have allowed us to port over existing servlet controllers with relative ease. We've included a portlet version of WebContentGenerator to give the controller classes their proper ancestry and provide control over things like content caching and access to the web application context and to centralized logging. We've also create a new set of the binding classes (PortletRequestDataBinder, PortletRequestParameterPropertyValues and PortletRequestBindingException) that support special field markers, correct problems with form elements such as radio buttons and checkboxes, and handle redisplay of invalid submits of non-string parameters properly. All of the classes are fully documented, including workflow descriptions in the controllers that cover the special nature of portlet development. Our hope is that these classes can handle the needs of everyone working with form controllers in Spring portlets and that these can be merged into the sandbox source code. The classes are posted in a zip file on the Spring Portlet Wiki page at: http://opensource.atlassian.com/confluence/spring/display/JSR168/ The link to the file is (sorry for the long link): http://opensource.atlassian.com/confluence/spring/download/attachments/10/sp ring-portlet-controllers.zip Please send me any questions or comments you may have about these classes. We are eager to support their adoption in the Spring Portlet community. John Lewis jl...@ar... ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Juergen H. <ju...@in...> - 2005-03-04 16:18:16
|
Well, the upcoming 1.2 RC1 might not be a bad occasion for this :-) I'll consider adding such a class to the org.springframework.web.filter package. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Oliver Hutchison Sent: Friday, March 04, 2005 12:03 AM To: spr...@li... Subject: RE: [Springframework-developer] GenericFilterBean dependency injection > Currently there is no way to inject dependencies into filter. > Instead, it must lookup for beans in application context. It > would be great to initialize fields of filter with beans, > corresponding to init-param values instead of with that > values themselves. Check out FilterToBeanProxy which is part of the Acegi project: http://acegisecurity.sourceforge.net/multiproject/acegi-security/apidocs /net/sf/acegisecurity/util/FilterToBeanProxy.html Hopefully this will become part of Spring core (hint) soon. Ollie ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=ick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Matt S. <sga...@us...> - 2005-03-04 15:23:13
|
OK, I see what you're getting at now. The problem is, how do you want Spring to figure out the mime type if it's not based on file extension? By dynamically inspecting the contents of the file at runtime? I know that's possible because IE does it, but that seems like it would be a pain to implement. Is there some other approach you could take, like storing the mime type information external to the file itself? Matt Andy Depue wrote: > From what I can tell, this appears to be related to JavaMail? If so, it is > not what I need. I'm using Spring's Resource interface to access, well, > general resources. Some of these resources actually end up residing on a web > server, and may even have a .jsp file extension - even though the .jsp page > might end up generating a binary file of some specific mime type, which > the .jsp page will manually set on output. In this case I cannot rely on > file extension. It would be useful if the Resource interface could expose to > me a simple way to inspect the mime type. If it is a classpath/file/simple > resource, then it could use the activation framework and detect the mime type > by the file extension (hiding all the gory details from me) - if it is a > Resource loaded from a web server, then it could return the mime type that > was returned by the web server - and so on. Am I approaching this the wrong > way? > > - Andy |
|
From: Darren D. <da...@sh...> - 2005-03-04 13:37:26
|
|
From: Ben A. <ben...@ac...> - 2005-03-04 05:11:53
|
Yaroslav Gnatyuk wrote: >Currently there is no way to inject dependencies into filter. Instead, >it must lookup for beans in application context. It would be great to >initialize fields of filter with beans, corresponding to init-param >values instead of with that values themselves. > > > http://acegisecurity.sourceforge.net/docbook/acegi.html#security-filters discusses two solutions: 1. FilterToBeanProxy, which loads a bean directly from your application context (where Spring wires them for you as normal) 2, FilterChainProxy, which is URI sensitive and fires whatever application context-defined Filters you like. Historically there was concern about lifecycle methods (ie should a servlet container manage the Filter lifecycle, or should the application context)? As per the docs, this is now configurable and defaults to expecting the application context to manage lifecycle. This is basically because the application context has far richer lifecycle methods than offered by the servlet container, and, more justifiably, a Filter that expects setters to be called is obviously IoC container aware and as such should be designed to use IoC lifecycle services as opposed to servlet container ones. Best regards Ben |
|
From: Martin K. <Mar...@St...> - 2005-03-04 00:32:14
|
Hi Juergen, Thanks for your reply. It made some points more clear. > <quote> > So in my oppinion the ApplicationContext should be placed in > org.springframework since beans, aop and context are only > exisiting to provide the functionality the ApplicationContext > needs (or better an implementation of the interface needed). > </quote> > > In fact, the beans and aop packages do not only exist to serve the > ApplicationContext. Spring is not a single system with a single entry > point: > In that respect, the Spring distribution is more similar to the JDK's > structure than it is to Hibernate's, for example. What I was about is the dependencies that the Spring framework draws. When I look on the composition model I noticed that the application context draws in most of the capabilities the bean package provides (Application context implements five diffrent interfaces /types). So those packages point their fingers to the man in the middle. That the bean package has some advantage when being used independently isn't something that I can not understand. Let me show you this: interface ApplicationContext extends: ListableBeanFactory -> beans (friendly) HierarchicalBeanFactory -> beans (friendly) MessageSource -> context (same) ApplicationEventPublisher -> context (same) ResourcePatternResolver -> core.io.support (friendly) One major gap are the ListableBeanFactory and the HierarchicalBeanFactory interfaces. Looking on the resulting ApplicationContex two special methods are imposed 1. getParent() : ApplicationContext 2. getParentFactory() : BeanFactory I think this indicates a mixed thinking. Parent and parent factory, can be somewhat diffrent but the domain should be clear. Maybe the application context should not pretend to be a bean factory first place (trade polymorphism for composition and therefore for responsibility) That is, what I was referring to. ApplicationContext solves the same tasks, like an ordinary bean factory do because it is(!) actually a bean factory. So the question goes, if application solves the same tasks a bean factory can and even some more, isn't it logical to think that a factory is a realisation of a feature of an application context? And if yes, wouldn't it mean that every time a user of the spring framework goes for a bean factory instead of a context, that the context is harder to use or misses some more key features? I understand that while implementing some of the features context/bean factory needs, it may provide some general purpose features, that may be usable on their own. But this general purpose features are no reason to not consider the beans package as a realisation of some of the tasks the application context has to deal with? The same thinking goes to the web context as well. All the association arrows point to the web context as being the spider in the web. > The beans package is completely independent and can > of course be used on its own, both at the BeanWrapper > level and at the BeanFactory level. The bean factory level is - in my thinking - the application context level. > Some people happily do either of the two, and don't care > about the context package (or any other Spring packages) at all. > > The beans package is also used internally by the JDBC support, > the validation package and other parts of Spring. No ApplicationContext > (or MessageSource etc) needed there, just low-level BeanWrapper > and/or BeanFactory functionality. Well I agree with that. But you can use the collections framework of the Java JDK outside of Java by just applying the described logic to a diffrent language. The collections framework is purpose driven. It exists to serve the Java language, but is also capable to serve other languages as well. > Quite a lot of people are using Spring's JDBC > support completely outside a Spring application > context, for example in custom DAOs or in custom EJBs. Well that is a point. But again I wouldn't see this as an argument against it. The JDBC support is part of the application context usage domain as well. It would justify to consider JDBC as a sub-project but not to be more important than the context. It is just an aspect of a special kind of applications (realise a persistance layer) > Only for applications that are fully architected on a Spring basis, an > ApplicationContext will play a central role. This is significantly > different > from a single-purpose tool such as Hibernate, where the > SessionFactory/Session combo plays a central role in all scenarios. I understand. But think about the Eclipse platform. The Eclipse folks at IBM build the SWT/JFace packages to serve the needs of the platform. But this support got so usefull that they made it a sub-project to be used independently, too. The fun part of it is that this swt and jface are still considered to mainly serve the platform's needs and that their independent usage is just a result of the overlappings of requirements from a diffrent target audience. > <quote> > For example, I am currently doing refactoring of > the DefaultXmlBeanDefinitionParser implementation. > > This is part of bean.factory.xml. In my thinking this is > wrong placement. The parser first of all should be > in a modul about parsers. But beside this you read > an application context definition file. Check out how > the dtd of spring is defined. All about beans. To > describe an application context you are referring to > the dtd. > </quote> > > Again, I tend to look at this from a different perspective: The > BeanFactory > stuff in the beans.factory package is the central part that deals with > bean > definitions. An ApplicationContext is "just" a higher-level facade for it, > adding auto-detection for special beans and additional services like a > MessageSource. The misplacing was also ment in form of refering it as xml package. XML is just a way to specifiy a factory. That's why I consider this a view or translation related task. You translate something into something more usable. This is what a parser mainly does. It converts form one language into another one. Thats why I would like to add this at least to a parser package. It is just a way to view things. But again I would consider this to be a context related issue, since by using a xml file this would also be understandable by an application context. So there is a replication of functionality here. You can read a context or a more special form (bean factory) from the same source, but you use diffrent features the framework provides. I don't like this duplication in responsibility. > Consequently, XML bean definition parsing does belong in > the beans.factory package, as it is "just" a special variant of > parsing bean definitions. XML bean definitions may be the > current main format for defining application contexts, but from > the framework point of view, it is just yet another bean definition > format and by no means central to all other parts of Spring. Thats why I don't like the beans module as it is currently shaped. Since this are exchanges of thoughts, there is no guarantee that we will reach a consensus at this topic. I guess this isn't also needed. I enjoy using the Spring framework because it is so more simplier than the EJB framework but I guess there is some room for improvements. Something just don't feel right and if I see the dependency graph, it just looks a bit too complicated for my experience. Never the less, thanks for developing the Spring framework, it saved me countless hours of work! (it still does...) Thanks and cheers, Martin (Kersten) PS: Thanks for your extense answer, I also wrote a more extense reply to honor your afford and your will to make me understand your position. I don't know if I could provide you some additional informations about my point of view. Maybe we reached a point where I have to provide some kind of proof for my claims which I can not deliver yet (but soon I will - in some months at least) |
|
From: Mason, R. <ros...@vi...> - 2005-03-03 23:36:38
|
Has Spring considered moving to a different provider? I have just moved Mule from SF to Codehaus and to be honest, it's a breathe of fresh air. CVS is quick, you can administer the repo yourself and support at Codehaus is excellent.=20 The only thing I'll miss from SF is the project stats, but they haven't worked for about 2 months anyway :( Just my 2c Ross >-----Original Message----- >From: spr...@li...=20 >[mailto:spr...@li...]=20 >On Behalf Of Matthew E.Porter >Sent: Thursday, 3 March 2005 12:57 AM >To: spr...@li... >Subject: Re: [Springframework-developer] SourceForge CVS > > >On Mar 2, 2005, at 6:50 AM, Patrick Burleson wrote: > >> On Wed, 2 Mar 2005 09:35:18 +0100, Erwin Vervaet=20 >> <erw...@er...> wrote: >>> The "SourceForge.net Sitewide Update: Feb 28th, 2005"=20 >mailing states=20 >>> the >>> following: >>> >>> * >>> We have a lot of improvements on the way for you. Our CVS upgrade=20 >>> will be online in the third week of March. You will see a marked=20 >>> improvement in checkin and checkout times as we roll out additional=20 >>> systems. I know this is good news to the many of you who=20 >use CVS on=20 >>> a regular basis. >>> * >>> >>> So there is light at the end of the tunnel! :) >>> >>> Erwin Vervaet >>> >> >> Haven't they been "upgrading CVS" for like 2 years? I don't=20 >think they=20 >> have ever gotten ahead of the problem. > >At this point, I think that message is just an automated=20 >header added to the mailings. This problem has been going on=20 >for 2 years and goes in waves. > > >Cheers, > Matthew > > > >------------------------------------------------------- >SF email is sponsored by - The IT Product Guide Read honest &=20 >candid reviews on hundreds of IT Products from real users. >Discover which products truly live up to the hype. Start reading now. >http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Oliver H. <Ol...@ou...> - 2005-03-03 23:03:07
|
> Currently there is no way to inject dependencies into filter.=20 > Instead, it must lookup for beans in application context. It=20 > would be great to initialize fields of filter with beans,=20 > corresponding to init-param values instead of with that=20 > values themselves. Check out FilterToBeanProxy which is part of the Acegi project: http://acegisecurity.sourceforge.net/multiproject/acegi-security/apidocs /net/sf/acegisecurity/util/FilterToBeanProxy.html Hopefully this will become part of Spring core (hint) soon. Ollie |
|
From: Yaroslav G. <gn...@gm...> - 2005-03-03 22:55:33
|
Currently there is no way to inject dependencies into filter. Instead, it must lookup for beans in application context. It would be great to initialize fields of filter with beans, corresponding to init-param values instead of with that values themselves. |
|
From: Ben A. <ben...@ac...> - 2005-03-03 21:22:37
|
Dear Spring Community I'm pleased to make the following two announcements: * Acegi Security will become a Spring subproject from release 1.0.0. * Acegi Security release 0.8.0 is now available. ===================================================================== OFFICIAL SUBPROJECT STATUS ===================================================================== Official subproject status means a closer relationship with the Spring Core project, broader adoption in Spring-powered projects, and the availability of quality professional services via Interface 21. A separate announcement will be published in the near future with additional details. Rod Johnson comments: "Subproject status for Acegi Security is overdue. Its quality and flexible design makes it a worthy part of the Spring family, and it exhibits the architectural consistency our users expect. Security is a core concern in the enterprise, and as in so many other areas a good generic framework offers tremendous value to developers. We're already seeing a lot of interest in the community and among our clients, and expect that adoption will progress in leaps and bounds with the 1.0.0 release." ===================================================================== RELEASE 0.8.0 ===================================================================== There are many improvements and fixes in release 0.8.0 (as listed at http://acegisecurity.sourceforge.net/changes-report.html). New features include: * Significant simplification of filter setup * Anonymous authentication support * Remember-me authentication support * Concurrent login prevention support * Digest authentication support (safer than BASIC authentication) * Source ZIPs for easier IDE integration, and nightly CVS snapshots * Various other fixes and improvements Most of these new features were added as a direct result of community feedback. We always welcome your feedback and suggestions. As per the Apache APR project versioning guidelines, this is a major release. We definitely expect the next major release will be 1.0.0, although release 0.8.0 should be considered stable enough for most projects to use. There are detailed upgrade instructions included in the release ZIP and on the Acegi Security home page. For Maven users, Acegi Security's latest JARs are available from http://acegisecurity.sourceforge.net/maven/acegisecurity/jars. Release 0.8.0 will be added to iBiblio very shortly. ===================================================================== FURTHER INFORMATION ===================================================================== Please visit http://acegisecurity.sourceforge.net to learn more about Acegi Security's features, browse online documentation, or download the latest release. We hope you find this new release useful in your projects. Cheers Ben |
|
From: John L. <jl...@ar...> - 2005-03-03 19:47:20
|
We've been working on porting a fairly complex enterprise application from the Spring Servlet MVC framework to the Spring Portlet MVC framework. As Nick Lothian and Rainer Schmitz discovered, the Form Controller hierarchy is difficult to port over from the Servlet area to the Portlet area because of the two-phase nature of portlet requests. Since we were porting a large number of existing controllers descended from AbstractController, AbstractFormController, or SimpleFormController, it was critical to that all the former functionality of these parent be present and that our logic work the same as before. Nick Lothian's version of SimplePortletFormController gave us a good starting point and helped us understand a lot of the issues with portlet development in general and with Spring portlets in particular. However, a lot of our controllers manage database content, so we needed proper separation between the action and render phase of the request, which this controller did not give us. Rainer Schmitz's work went much further and provided the traditional hierarchy of controllers and further demonstrated the issues with separating out the two phases of the portlet request. However, these still did not give us the complete control that we needed. We especially needed a version of SimpleFormController that could handle the separation of the action logic from the render logic. Over the past few months we have developed a new set of the AbstractController, BaseCommandController, AbstractFormController, and SimpleFormController classes that we think rigorously address all the issues with portlet development and that have allowed us to port over existing servlet controllers with relative ease. We've included a portlet version of WebContentGenerator to give the controller classes their proper ancestry and provide control over things like content caching and access to the web application context and to centralized logging. We've also create a new set of the binding classes (PortletRequestDataBinder, PortletRequestParameterPropertyValues and PortletRequestBindingException) that support special field markers, correct problems with form elements such as radio buttons and checkboxes, and handle redisplay of invalid submits of non-string parameters properly. All of the classes are fully documented, including workflow descriptions in the controllers that cover the special nature of portlet development. Our hope is that these classes can handle the needs of everyone working with form controllers in Spring portlets and that these can be merged into the sandbox source code. The classes are posted in a zip file on the Spring Portlet Wiki page at: http://opensource.atlassian.com/confluence/spring/display/JSR168/ The link to the file is (sorry for the long link): http://opensource.atlassian.com/confluence/spring/download/attachments/10/spring-portlet-controllers.zip Please send me any questions or comments you may have about these classes. We are eager to support their adoption in the Spring Portlet community. John Lewis jl...@ar... |
|
From: Andy D. <an...@ma...> - 2005-03-03 18:54:19
|
=46rom what I can tell, this appears to be related to JavaMail? If so, it = is=20 not what I need. I'm using Spring's Resource interface to access, well,=20 general resources. Some of these resources actually end up residing on a w= eb=20 server, and may even have a .jsp file extension - even though the .jsp page= =20 might end up generating a binary file of some specific mime type, which=20 the .jsp page will manually set on output. In this case I cannot rely on=20 file extension. It would be useful if the Resource interface could expose = to=20 me a simple way to inspect the mime type. If it is a classpath/file/simple= =20 resource, then it could use the activation framework and detect the mime ty= pe=20 by the file extension (hiding all the gory details from me) - if it is a=20 Resource loaded from a web server, then it could return the mime type that= =20 was returned by the web server - and so on. Am I approaching this the wron= g=20 way? - Andy On Thursday 03 March 2005 10:12 am, Matt Sgarlata wrote: > The mime type support in Spring is based on the mime type support in the > Java Activation Framework. There are plans to add additional MIME types > to Spring. See: > > http://opensource.atlassian.com/projects/spring/browse/SPR-637 > > Does this answer your question? > > Matt |
|
From: Matt S. <sga...@us...> - 2005-03-03 18:39:53
|
The mime type support in Spring is based on the mime type support in the Java Activation Framework. There are plans to add additional MIME types to Spring. See: http://opensource.atlassian.com/projects/spring/browse/SPR-637 Does this answer your question? Matt Andy Depue wrote: > I'm wondering if there are any plans on adding some kind of mime type to > org.springframework.core.io.Resource? If I load a resource whose type I > don't know in advance, I currently have no way to tell what type it is other > than parsing the file name for an extension or attempting to deduce it from > the InputStream (not fun). > > Thanks, > Andy > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click |