springframework-developer — Spring Framework developers list

RE: [Springframework-developer] Spring Portlet MVC layer is rendering JSTL Views!!!

[Mason, R. <ros...@vi...>]

RmFudGFzdGljISAgeW91ciB0aW1pbmcgaXMgaW1wZWNjYWJsZSBhcyBJJ20gZG9pbmcgc29tZSB3
b3JrIHdpdGggU3ByaW5nIGFuZCBhIGNvbW1lcmNpYWwgcG9ydGFsIGF0IHRoZSBtb21lbnQsIGJ1
dCB3ZSBoYXZlbid0IG1hZGUgYSBkZXNpc2lvbiBvbiB0aGUgcHJlc2VudGF0aW9uIHlldC4NCiAN
Ckxvb2tpbmcgZm9yd2FyZCB0byBwbGF5aW5nIHdpdGggaXQuDQogDQpDaGVlcnMsDQogDQpSb3Nz
DQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBXaWxsaWFtIEcuIFRob21w
c29uLCBKci4gW21haWx0bzp3Z3Rob21AcnV0Z2Vycy5lZHVdIA0KCVNlbnQ6IFRodSAyOS8wNC8y
MDA0IDM6MzAgQU0gDQoJVG86IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNl
Zm9yZ2UubmV0IA0KCUNjOiBteXJ1dGdlcnNAc3VyZnNpZGUucnV0Z2Vycy5lZHU7IEZyZWRkeSBM
b3BlejsgS2VuIFdlaW5lciANCglTdWJqZWN0OiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0g
U3ByaW5nIFBvcnRsZXQgTVZDIGxheWVyIGlzIHJlbmRlcmluZyBKU1RMIFZpZXdzISEhDQoJDQoJ
DQoNCglGb2xrcywNCgkNCglTcHJpbmcgUG9ydGxldCBNVkMgbGF5ZXIgaXMgcmVuZGVyaW5nIEpT
VEwgVmlld3Mgd2l0aCBmdWxsDQoJQXBwbGljYXRpb25Db250ZXh0IHN1cHBvcnQhISENCgkNCglJ
IGVuZGVkIGhhdmluZyB0byBwb3J0IGp1c3QgYWJvdXQgdGhlIGVudGlyZQ0KCW9yZy5zcHJpbmdm
cmFtZXdvcmsud2ViLnNlcnZsZXQuKiBwYWNrYWdlLg0KCQ0KCVNob3VsZCB0aGlzIGdvIGludG8g
dGhlIHNhbmRib3g/ICBJIHN1c3BlY3QgdGhhdCBpdCBtYXkgc3RpbGwgbmVlZCBzb21lDQoJcmVm
YWN0b3JpbmcuLi5hZnRlciB3ZSBwbGF5IHdpdGggaXQgYSBiaXQgbW9yZS4NCgkNCglsYXRlci4N
CglCaWxsDQoJLS0NCglXaWxsaWFtIEcuIFRob21wc29uLCBKci4NCglBc3NvY2lhdGUgRGlyZWN0
b3Igb2YgTmV3IFRlY2hub2xvZ2llcw0KCUFkbWluaXN0cmF0aXZlIENvbXB1dGluZyBTZXJ2aWNl
cywgUnV0Z2VycyBVbml2ZXJzaXR5DQoJdm9pY2U6IDczMiA0NDUtNTQyOCB8IGZheDogNzMyIDQ0
NS01NDkzIHwgd2d0aG9tQHJ1dGdlcnMuZWR1DQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgU0YuTmV0IGVtYWls
IGlzIHNwb25zb3JlZCBieTogT3JhY2xlIDEwZw0KCUdldCBjZXJ0aWZpZWQgb24gdGhlIGhvdHRl
c3QgdGhpbmcgZXZlciB0byBoaXQgdGhlIG1hcmtldC4uLiBPcmFjbGUgMTBnLg0KCVRha2UgYW4g
T3JhY2xlIDEwZyBjbGFzcyBub3csIGFuZCB3ZSdsbCBnaXZlIHlvdSB0aGUgZXhhbSBGUkVFLg0K
CWh0dHA6Ly9hZHMub3Nkbi5jb20vP2FkX2lkPTMxNDkmYWxsb2NfaWQ9ODE2NiZvcD1jbGljaw0K
CV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJU3ByaW5n
ZnJhbWV3b3JrLWRldmVsb3BlciBtYWlsaW5nIGxpc3QNCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxv
cGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KCWh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0
L2xpc3RzL2xpc3RpbmZvL3NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXINCgkNCg0K

Re: [Springframework-developer] Cleanup of context resources on webapp reload

[Dmitriy K. <dko...@ru...>]

I'm just wondering, would the use of WeakHashMap in CachedIntrospectionResults help?

Dmitriy.

Tim Kettering wrote:

> 
> I posted this to the users list last week and did not receive any reply  
> on it, so I'm posting it again here on the developer list, in hopes i  
> could get an reply from someone here.   I'm trying to determine if its  
> something I should be doing myself, or if hte spring context should be  
> cleaning up those resources by itself on the .close() call.  Further  
> profiling shows that there are duplicate instances of SQLError and  
> hibernate proxy classes hanging around afterwards too.  Other objects  
> do get cleaned up properly.
> 
> --------
> Hi everyone,
> 
> We're (meaning me) looking into some resource leaks that are occuring  
> when our webapp context gets reloaded.  I found that context.close()  
> needs to be called on the destroy() method of plugin we're using, and  
> it works for a good majority of the objects we were seeing leaked, but  
> there are some objects that I'm unable to make go away. Object in  
> question is the:
> 
> org.springframework.beans.CachedIntrospectionResults
> 
> Whenever I reload the context - the profiler I'm using shows that I  
> have essentially a duplicate group of those objects (same instance  
> count) as the original, and successive reloads will continue to  
> duplicate this.
> 
> The profiler also shows the final reference to those objects like this:
> 
> 100% - 1008 bytes - 63 alloc.  
> org.springframework.context.support.ClassPathXmlApplicationContext.<init >
> 
> So basically I guess what I'm asking is for ideas or suggestions on how  
> I could get those to clean up.  This bean doesnt show up in the Spring  
> javadocs.  And looking in CVS says its a package level bean, not for  
> application use, so I'm thinking that closing the context should (in  
> theory) clean this up?   Thanks in advance.
> 
> -tim
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE. 
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Cleanup of context resources on webapp reload

[Tim K. <tim...@vi...>]

I posted this to the users list last week and did not receive any reply  
on it, so I'm posting it again here on the developer list, in hopes i  
could get an reply from someone here.   I'm trying to determine if its  
something I should be doing myself, or if hte spring context should be  
cleaning up those resources by itself on the .close() call.  Further  
profiling shows that there are duplicate instances of SQLError and  
hibernate proxy classes hanging around afterwards too.  Other objects  
do get cleaned up properly.

--------
Hi everyone,

We're (meaning me) looking into some resource leaks that are occuring  
when our webapp context gets reloaded.  I found that context.close()  
needs to be called on the destroy() method of plugin we're using, and  
it works for a good majority of the objects we were seeing leaked, but  
there are some objects that I'm unable to make go away. Object in  
question is the:

org.springframework.beans.CachedIntrospectionResults

Whenever I reload the context - the profiler I'm using shows that I  
have essentially a duplicate group of those objects (same instance  
count) as the original, and successive reloads will continue to  
duplicate this.

The profiler also shows the final reference to those objects like this:

100% - 1008 bytes - 63 alloc.  
org.springframework.context.support.ClassPathXmlApplicationContext.<init 
 >

So basically I guess what I'm asking is for ideas or suggestions on how  
I could get those to clean up.  This bean doesnt show up in the Spring  
javadocs.  And looking in CVS says its a package level bean, not for  
application use, so I'm thinking that closing the context should (in  
theory) clean this up?   Thanks in advance.

-tim

Re: [Springframework-developer] Exposing LOB support to Jdbc Object layer

[<tho...@tr...>]

Don't know yet where the close of the LobCreator should happen.  Should be
right
after ps.executeUpdate() so we would need to qyery the PreparedStatementCreator
for LOB info somehow.  I have not looked at the batch processing or
MappingSqlQuery usage yet.  

I'm still in the expreimentation stage but I would like to have this ready for
1.1.  We would need to test with various transaction scenarios.  PostgreSQL
requires that you don't run in autocommit mode when you insert a BLOB.

Thomas


Quoting "jürgen höller [werk3AT]" <jue...@we...>:

> That looks interesting! I didn't think about overloaded SqlParameter =
> constructors before; that definitely makes sense. How to you handle the =
> LobCreator lifecycle there? LobCreator.close needs to be invoked after =
> PreparedStatement execution (but before transaction completion).
> 
> BTW, I've recently refined the LOB support for jdbc.core: There are =
> AbstractLobCreatingPreparedStatementCallback and =
> AbstractLobStreamingResultSetExtractor classes now (don't we love our =
> class naming patterns!), to make LOB handling via JdbcTemplate more =
> convenient. Have a look at imagedb's DefaultImageDatabase class for =
> usage examples.
> 
> There's also a ClobStringType class in our Hibernate support, for =
> storing String properties in CLOB fields. That allows to transparently =
> store long Strings in Oracle CLOBs respectively MySQL text fields, for =
> example. It registers a TransactionSynchronization for the =
> LobCreator.close call, so just works within a Spring transaction.
> 
> Juergen
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Thomas Risberg
> Sent: Monday, May 03, 2004 2:58 AM
> To: spr...@li...
> Subject: [Springframework-developer] Exposing LOB support to Jdbc Object
> layer
> 
> 
> I've recently started to take a closer look at Juergen's LOB handler=20
> classes and they look very solid.  It would be a shame not exposing them =
> 
> to the Jdbc Object package - primarily SqlUpdate.  I have started to=20
> test a few ideas.  I added a constructor accepting a LobHandler to the=20
> SqlParameter class.  I also added a SqlLobValue class for holding the=20
> input stream and the length.  This is what the usage would look like:
> 
>         LobHandler lobHandler =3D new DefaultLobHandler();  // or=20
> OracleLobHandler
>         String sql =3D "insert into docs (doc_id, description , added,=20
> document) values(?, ?, ?, ?)";
>         SqlUpdate su =3D new SqlUpdate(ds, sql);
>         su.declareParameter(new SqlParameter("id", Types.INTEGER));
>         su.declareParameter(new SqlParameter("desc", Types.VARCHAR));
>         su.declareParameter(new SqlParameter("added", Types.DATE));
>         su.declareParameter(new SqlParameter("lob", Types.BLOB,=20
> lobHandler));
>         su.compile();
>         Object[] inval =3D new Object[4];
>         inval[0] =3D new Integer(newId);
>         inval[1] =3D "Doc One";
>         inval[2] =3D new java.sql.Date(new Date().getTime());
>         File in =3D new File("word.doc");
>         int len =3D (int) in.length();
>         FileInputStream is =3D new FileInputStream(in);
>         inval[3] =3D new SqlLobValue(is, len);
>         int count =3D su.update(inval);
>         is.close();
> 
> A few tweaks to the PreparedStatementCreateorImpl class and this=20
> actually ran against both Oracle and PostgreSQL.
> 
> I think we could easily support all the different methods that=20
> LobHandler supports:
>  byte[]
>  BinaryStream
>  String
>  AsciiStream
>  CharacterStream
> 
> Any thoughts or ideas?
> 
> Thomas
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. =
> 
> Take an Oracle 10g class now, and we'll give you the exam FREE.=20
> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE. 
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] Spring Portlet MVC layer is rendering JSTL Views!!!

[Dmitriy K. <dko...@ru...>]

Mike, everybody,

I've posted the design discussion with Juergen to the JSR 168 space: http://opensource.atlassian.com/confluence/spring/display/JSR168/SpringPortlet+module+design+discussion

Regards,
Dmitriy.


Mike Cannon-Brookes wrote:

> Bill,
> 
> Excellent work - this looks superb (I can't try it now but will do when 
> I get back to the office next week). The document below looks good, and 
> likely to get lost in the mailing list - is it stored somewhere else? 
> readme / wiki / docs?
> 
> M
> -- 
> ATLASSIAN - http://www.atlassian.com/
> 
> Confluence - the professional J2EE wiki - tried it yet?
> http://www.atlassian.com/confluence/
> 
> On 02/05/2004, at 1:14 AM, William G. Thompson, Jr. wrote:
> 
>> Folks,
>>
>> I have packaged up a Portlet Application that may be of interest.  The 
>> war file is available at:
>>   http://www.tnt-web.com/springportlet/springportlet.war
>>
>> You should be able to download the war file and then deploy using the 
>> tools for whatever portlet container you are using.  I'm running this 
>> with uPortal2.3 which embeds Pluto.
>>
>>
>> There are two portlets defined in WEB-INF/portlet.xml
>>
>> 1) InspectPortlet - a "fat" portlet that displays various bits of info 
>> available through the Portlet API (built using only GenericPortlet)
>>
>> 2) ExampleSpringPortlet - proof-of-concept portlet built using Spring 
>> MVC layer adapted for the Portlet API.  The portlet name maps to a 
>> DispatcherPortlet which bootstraps:
>>   a) applicationContext.xml - the root PortletApplicationContext
>>   b) ExampleSpringPortlet-portlet.xml - config for the named 
>> DispatcherPortlet (handler mappings, view resolvers, controllers, etc.)
>>
>> As configured, ExampleSpringPortlet simply maps PortletModes to view 
>> names and finally dispatches to JSPs:
>>   WEB-INF/jsp/portlet/view.jsp
>>   WEB-INF/jsp/portlet/edit.jsp
>>   WEB-INF/jsp/portlet/help.jsp
>>
>> The Portlet API defines a tag-lib as well and I use that to generate 
>> the RenderURLs you will see in the views.
>>
>> later.
>> Bill
>>
>> ps.  If you are using uPortal2.3 here are the deploy steps:
>> 1) ant deployPortletApp -DportletApp=/path/to/springportlet.war
>> 2) bounce tomcat
>> 3) using the Channel Manager define two new Portlet Channels.  The 
>> portlet Ids are:
>>   springportlet.InspectPortlet
>>   springportlet.ExampleSpringPortlet
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: Oracle 10g
>> Get certified on the hottest thing ever to hit the market... Oracle 
>> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. 
>> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE. 
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Exposing LOB support to Jdbc Object layer

[Colin S. <col...@ex...>]

j=FCrgen h=F6ller [werk3AT] wrote:

>That looks interesting! I didn't think about overloaded SqlParameter con=
structors before; that definitely makes sense. How to you handle the LobC=
reator lifecycle there? LobCreator.close needs to be invoked after Prepar=
edStatement execution (but before transaction completion).
>
>BTW, I've recently refined the LOB support for jdbc.core: There are Abst=
ractLobCreatingPreparedStatementCallback and AbstractLobStreamingResultSe=
tExtractor classes now (don't we love our class naming patterns!), to mak=
e LOB handling via JdbcTemplate more convenient. Have a look at imagedb's=
 DefaultImageDatabase class for usage examples.
>
>There's also a ClobStringType class in our Hibernate support, for storin=
g String properties in CLOB fields. That allows to transparently store lo=
ng Strings in Oracle CLOBs respectively MySQL text fields, for example. I=
t registers a TransactionSynchronization for the LobCreator.close call, s=
o just works within a Spring transaction.
> =20
>
I've been trying to convince Gavin for ages to make it possible to lazy=20
load columns (not just collections), which would make stuff like=20
ClobStringType a lot more useful. Right now if you have a table with a=20
LOB column and use something like ClobStringType you pay the price and=20
load it even if you don't need it.

Oh well...

Re: [Springframework-developer] Spring Portlet MVC layer is rendering JSTL Views!!!

[Mike Cannon-B. <mi...@at...>]

Bill,

Excellent work - this looks superb (I can't try it now but will do when 
I get back to the office next week). The document below looks good, and 
likely to get lost in the mailing list - is it stored somewhere else? 
readme / wiki / docs?

M
--
ATLASSIAN - http://www.atlassian.com/

Confluence - the professional J2EE wiki - tried it yet?
http://www.atlassian.com/confluence/

On 02/05/2004, at 1:14 AM, William G. Thompson, Jr. wrote:

> Folks,
>
> I have packaged up a Portlet Application that may be of interest.  The 
> war file is available at:
>   http://www.tnt-web.com/springportlet/springportlet.war
>
> You should be able to download the war file and then deploy using the 
> tools for whatever portlet container you are using.  I'm running this 
> with uPortal2.3 which embeds Pluto.
>
>
> There are two portlets defined in WEB-INF/portlet.xml
>
> 1) InspectPortlet - a "fat" portlet that displays various bits of info 
> available through the Portlet API (built using only GenericPortlet)
>
> 2) ExampleSpringPortlet - proof-of-concept portlet built using Spring 
> MVC layer adapted for the Portlet API.  The portlet name maps to a 
> DispatcherPortlet which bootstraps:
>   a) applicationContext.xml - the root PortletApplicationContext
>   b) ExampleSpringPortlet-portlet.xml - config for the named 
> DispatcherPortlet (handler mappings, view resolvers, controllers, 
> etc.)
>
> As configured, ExampleSpringPortlet simply maps PortletModes to view 
> names and finally dispatches to JSPs:
>   WEB-INF/jsp/portlet/view.jsp
>   WEB-INF/jsp/portlet/edit.jsp
>   WEB-INF/jsp/portlet/help.jsp
>
> The Portlet API defines a tag-lib as well and I use that to generate 
> the RenderURLs you will see in the views.
>
> later.
> Bill
>
> ps.  If you are using uPortal2.3 here are the deploy steps:
> 1) ant deployPortletApp -DportletApp=/path/to/springportlet.war
> 2) bounce tomcat
> 3) using the Channel Manager define two new Portlet Channels.  The 
> portlet Ids are:
>   springportlet.InspectPortlet
>   springportlet.ExampleSpringPortlet
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 
> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. 
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Exposing LOB support to Jdbc Object layer

[<jue...@we...>]

That looks interesting! I didn't think about overloaded SqlParameter =
constructors before; that definitely makes sense. How to you handle the =
LobCreator lifecycle there? LobCreator.close needs to be invoked after =
PreparedStatement execution (but before transaction completion).

BTW, I've recently refined the LOB support for jdbc.core: There are =
AbstractLobCreatingPreparedStatementCallback and =
AbstractLobStreamingResultSetExtractor classes now (don't we love our =
class naming patterns!), to make LOB handling via JdbcTemplate more =
convenient. Have a look at imagedb's DefaultImageDatabase class for =
usage examples.

There's also a ClobStringType class in our Hibernate support, for =
storing String properties in CLOB fields. That allows to transparently =
store long Strings in Oracle CLOBs respectively MySQL text fields, for =
example. It registers a TransactionSynchronization for the =
LobCreator.close call, so just works within a Spring transaction.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Thomas Risberg
Sent: Monday, May 03, 2004 2:58 AM
To: spr...@li...
Subject: [Springframework-developer] Exposing LOB support to Jdbc Object
layer


I've recently started to take a closer look at Juergen's LOB handler=20
classes and they look very solid.  It would be a shame not exposing them =

to the Jdbc Object package - primarily SqlUpdate.  I have started to=20
test a few ideas.  I added a constructor accepting a LobHandler to the=20
SqlParameter class.  I also added a SqlLobValue class for holding the=20
input stream and the length.  This is what the usage would look like:

        LobHandler lobHandler =3D new DefaultLobHandler();  // or=20
OracleLobHandler
        String sql =3D "insert into docs (doc_id, description , added,=20
document) values(?, ?, ?, ?)";
        SqlUpdate su =3D new SqlUpdate(ds, sql);
        su.declareParameter(new SqlParameter("id", Types.INTEGER));
        su.declareParameter(new SqlParameter("desc", Types.VARCHAR));
        su.declareParameter(new SqlParameter("added", Types.DATE));
        su.declareParameter(new SqlParameter("lob", Types.BLOB,=20
lobHandler));
        su.compile();
        Object[] inval =3D new Object[4];
        inval[0] =3D new Integer(newId);
        inval[1] =3D "Doc One";
        inval[2] =3D new java.sql.Date(new Date().getTime());
        File in =3D new File("word.doc");
        int len =3D (int) in.length();
        FileInputStream is =3D new FileInputStream(in);
        inval[3] =3D new SqlLobValue(is, len);
        int count =3D su.update(inval);
        is.close();

A few tweaks to the PreparedStatementCreateorImpl class and this=20
actually ran against both Oracle and PostgreSQL.

I think we could easily support all the different methods that=20
LobHandler supports:
 byte[]
 BinaryStream
 String
 AsciiStream
 CharacterStream

Any thoughts or ideas?

Thomas


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. =

Take an Oracle 10g class now, and we'll give you the exam FREE.=20
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] velocity encoding

[Ales J. <ale...@ge...>]

Hi!

Although I have all these encode settings set, I still don't get the =
correct output.
What can be the problem?

10x!

Ales

--- settings (in different files) ---

# view encoding
parentVelocityView.encoding=3DWindows-1250

# velocityConfig (VelocityConfigurer)
        <property name=3D"velocityProperties">
            <props>
                <prop key=3D"input.encoding">Windows-1250</prop>
                <prop key=3D"output.encoding">Windows-1250</prop>
            </props>
        </property>

[Springframework-developer] Exposing LOB support to Jdbc Object layer

[Thomas R. <tho...@tr...>]

I've recently started to take a closer look at Juergen's LOB handler 
classes and they look very solid.  It would be a shame not exposing them 
to the Jdbc Object package - primarily SqlUpdate.  I have started to 
test a few ideas.  I added a constructor accepting a LobHandler to the 
SqlParameter class.  I also added a SqlLobValue class for holding the 
input stream and the length.  This is what the usage would look like:

        LobHandler lobHandler = new DefaultLobHandler();  // or 
OracleLobHandler
        String sql = "insert into docs (doc_id, description , added, 
document) values(?, ?, ?, ?)";
        SqlUpdate su = new SqlUpdate(ds, sql);
        su.declareParameter(new SqlParameter("id", Types.INTEGER));
        su.declareParameter(new SqlParameter("desc", Types.VARCHAR));
        su.declareParameter(new SqlParameter("added", Types.DATE));
        su.declareParameter(new SqlParameter("lob", Types.BLOB, 
lobHandler));
        su.compile();
        Object[] inval = new Object[4];
        inval[0] = new Integer(newId);
        inval[1] = "Doc One";
        inval[2] = new java.sql.Date(new Date().getTime());
        File in = new File("word.doc");
        int len = (int) in.length();
        FileInputStream is = new FileInputStream(in);
        inval[3] = new SqlLobValue(is, len);
        int count = su.update(inval);
        is.close();

A few tweaks to the PreparedStatementCreateorImpl class and this 
actually ran against both Oracle and PostgreSQL.

I think we could easily support all the different methods that 
LobHandler supports:
 byte[]
 BinaryStream
 String
 AsciiStream
 CharacterStream

Any thoughts or ideas?

Thomas

[Springframework-developer] EasyMock 1.1

[Colin S. <col...@ex...>]

I've checked in EasyMock 1.1, including an easymockclassextension.jar, 
which allows mocking of classes (via cglib), not just interfaces. It's 
pretty useful in some circumstances.

(btw, I have personally been using JMock (http://jmock.codehaus.org) 
lately, created by some of the original MockObjects people. It seems to 
have finally stabilized to the point where it's safe to use without 
worrying about having to make changes later, and  I generally prefer it 
to EasyMock most of the time.

Here's the new stuff in EasyMock 1.1:
---

EasyMock Version 1.1 (May 3 2004)

Changes since 1.0.1b:

    * A first extension for EasyMock is available. With the help of
      cglib, it allows generating mock objects for classes. It is
      available in an own jar file from the EasyMock home page.
    * ParameterMatcher renamed to ArgumentsMatcher, since it matches
      arguments, not parameters
    * parameterMatches() and parameterToString() on AbstractMatcher
      renamed to argumentMatches() and argumentToString(), since they
      work on arguments, not parameters
    * tests extended to gain 100% clover coverage
    * internal refactorings
    *

Re: [Springframework-developer] Testing Controllers and FormControllers

[Luke T. <ne...@fr...>]

jürgen höller [werk3AT] wrote:

> While I object to keeping our new mocks in the "test" tree, I'm not
> against keeping them in the "src" tree, excluding them from
> spring.jar and Clover coverage. Rod was quite keen on having the
> separate "mock" tree, so I guess we need to wait for his opinion,
> taking into account the Maven issue. Unfortunately, he won't be
> online before Tuesday morning...
> 

I managed to get it to work OK with only a minor hack, so the reports 
and doc generation are running OK again.

> In any case, it's important to agree on this before 1.0.2, which is
> currently scheduled for release in two weeks.
> 

Just one other minor request... Could you bump the version number in the 
Maven project.xml file whenever you tag a release? It'll keep the 
version listed on the site in line with the current codebase. Come to 
think of it, I should change it from 1.0 which is what it's reporting at 
the moment...

Luke.


-- 
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk

Re: [Springframework-developer] Testing Controllers and FormControllers

[Thomas R. <tho...@tr...>]

There is a SpringMockDataSource in the 
org.springframework.jdbc.support.SQLErrorCodesFactoryTests class. Don't 
think it is of any value for general use right now, but it was needed 
for the translation factory tests since every single instance of the 
easy mock datasource always returned the same hash value.

Thomas

jürgen höller [werk3AT] wrote:

>I don't think that a separate mock module makes much sense: After all, the "test" tree of the framework itself depends on those mocks... It really should stay part of the main module. As you say, it's also easier in terms of release management.
> 
>I don't think that the mocks will grow into something with its own release schedule: We're still recommending dynamic mocks a la EasyMock for most testing scenarios. Just when interfaces are really hard to mock dynamically because of inter-dependent and overlapping methods (attribute handling, parameters), we provide distinct mock objects: currently, just for the Servlet API and for JNDI. The only further candidate that I can think of at this point of time is the Portlet API.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Alef Arendsen
>Gesendet: So 02.05.2004 16:18
>An: spr...@li...
>Betreff: RE: [Springframework-developer] Testing Controllers and FormControllers
>
>
>
>  
>
>>I'd still prefer a separate tree. More for clarity when users
>>browse code. A lot of people are likely to look at the source
>>in the /src tree and be confused as to why there's test-
>>related stuff there that isn't in spring.jar.
>>    
>>
>+1
>
>It will result in all kinds of questions popping up on the lists.
>
>What about a separate module? Or did I miss the discussion there. It would
>allow for separate development of the mock tree (and maybe other
>test-related stuff). I imagine the amount of test-related supporting
>features for 1.0.x to grow before 1.1 is released and people will be able to
>use those enhancements as they are contained by separate releases (as
>opposed to having them in the src or mock tree alongside the 1.0.x codebase
>which might not be getting another release anymore).
>
>A separate module does however result in more complexity and work when doing
>releases and stuff maybe...
>
>Alef
>  
>
>>Rgds,
>>Rod
>>
>>---- Original message ----
>>    
>>
>>>Date: Sun, 2 May 2004 13:26:29 +0200
>>>From: jürgen höller [werk3AT] <jue...@we...>
>>>Subject: Re: [Springframework-developer] Testing Controllers
>>>      
>>>
>>and FormControllers
>>    
>>
>>>To: <spr...@li...>
>>>
>>>While I object to keeping our new mocks in the "test" tree,
>>>      
>>>
>>I'm not against keeping them in the "src" tree, excluding
>>them from spring.jar and Clover coverage. Rod was quite keen
>>on having the separate "mock" tree, so I guess we need to
>>wait for his opinion, taking into account the Maven issue.
>>Unfortunately, he won't be online before Tuesday morning...
>>    
>>
>>>In any case, it's important to agree on this before 1.0.2,
>>>      
>>>
>>which is currently scheduled for release in two weeks.
>>    
>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: spr...@li...
>>>      
>>>
>>im Auftrag von Luke Taylor
>>    
>>
>>>Gesendet: Fr 30.04.2004 21:44
>>>An: spr...@li...
>>>Betreff: Re: [Springframework-developer] Testing Controllers
>>>      
>>>
>>and FormControllers
>>    
>>
>>>
>>>My main concern isn't so much whether they are in the test
>>>      
>>>
>>or src tree,
>>    
>>
>>>it's just that the overall structure seems a bit haphazard.
>>>      
>>>
>>And I don't
>>    
>>
>>>see why they should be split from the core when other
>>>      
>>>
>>modules aren't.
>>    
>>
>>>If separate modules are going to be split from the codebase
>>>      
>>>
>>then it
>>    
>>
>>>would make sense to follow a standard pattern, e.g.
>>>
>>>core
>>> |
>>>  - src
>>> |
>>>  - test
>>>
>>>mock
>>> |
>>>  - src
>>>
>>>other
>>> |
>>>  - src
>>> |
>>>  - test
>>>
>>>Ok, Ok... so my main concern is that it won't work with my
>>>      
>>>
>>Maven build
>>    
>>
>>>unless I hack it :) and until then my reports are stuck at
>>>      
>>>
>>Apr 28th. But
>>    
>>
>>>I agree with the aims Maven had of establishing a common
>>>      
>>>
>>structure for
>>    
>>
>>>project layouts, even though you could easily argue that
>>>      
>>>
>>they aren't
>>    
>>
>>>exactly a shining example of best practice development
>>>      
>>>
>>themselves.
>>    
>>
>>>Luke.
>>>
>>>jürgen höller [werk3AT] wrote:
>>>      
>>>
>>>>IMO, there's a strong difference between the "mock" and
>>>>        
>>>>
>>the "test"
>>    
>>
>>>>tree: The latter is a rough test suite for the framework
>>>>        
>>>>
>>itself,
>>    
>>
>>>>while the former contains polished mock classes that are
>>>>        
>>>>
>>also useful
>>    
>>
>>>>for applications, thus get distributed as "spring-
>>>>        
>>>>
>>mock.jar". The
>>    
>>
>>>>mocks would even fit better in "src" than in "test" in
>>>>        
>>>>
>>that respect.
>>    
>>
>>>>Actually, the "mock" tree is more similar to the
>>>>        
>>>>
>>main "src" tree than
>>    
>>
>>>>the "test" tree in a number of respects: It's meant to be
>>>>        
>>>>
>>used by
>>    
>>
>>>>applications, shipped as jar , included in the javadoc,
>>>>        
>>>>
>>and requires
>>    
>>
>>>>higher coding standards than the framework test suite. I'm
>>>>        
>>>>
>>quite
>>    
>>
>>>>strongly against keeping that sort of classes in
>>>>        
>>>>
>>the "test" tree.
>>    
>>
>>>>Juergen
>>>>
>>>>
>>>>        
>>>>
>>>
>>>--
>>> Luke Taylor.                      Monkey Machine Ltd.
>>> PGP Key ID: 0x57E9523C
>>>      
>>>
>>http://www.monkeymachine.ltd.uk
>>    
>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by: Oracle 10g
>>>Get certified on the hottest thing ever to hit the market...
>>>      
>>>
>>Oracle 10g.
>>    
>>
>>>Take an Oracle 10g class now, and we'll give you the exam
>>>      
>>>
>>FREE.
>>    
>>
>>>http://ads.osdn.com/?ad_id149&alloc_id66&op=click
>>>_______________________________________________
>>>Springframework-developer mailing list
>>>Spr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/springframework-
>>>      
>>>
>>developer
>>    
>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by: Oracle 10g
>>>Get certified on the hottest thing ever to hit the market...
>>>      
>>>
>>Oracle 10g.
>>    
>>
>>>Take an Oracle 10g class now, and we'll give you the exam
>>>      
>>>
>>FREE.
>>    
>>
>>>http://ads.osdn.com/?ad_id149&alloc_id66&opÀick
>>>_______________________________________________
>>>Springframework-developer mailing list
>>>Spr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/springframework-
>>>      
>>>
>>developer
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: Oracle 10g
>>Get certified on the hottest thing ever to hit the market... Oracle 10g.
>>Take an Oracle 10g class now, and we'll give you the exam FREE.
>>http://ads.osdn.com/?ad_id149&alloc_id66&op=ick
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>    
>>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g.
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id149&alloc_id66&op=ick
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE. 
>http://ads.osdn.com/?ad_id149&alloc_id66&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>  
>

Re: [Springframework-developer] Testing Controllers and FormControllers

[<jue...@we...>]

I don't think that a separate mock module makes much sense: After all, =
the "test" tree of the framework itself depends on those mocks... It =
really should stay part of the main module. As you say, it's also easier =
in terms of release management.
=20
I don't think that the mocks will grow into something with its own =
release schedule: We're still recommending dynamic mocks a la EasyMock =
for most testing scenarios. Just when interfaces are really hard to mock =
dynamically because of inter-dependent and overlapping methods =
(attribute handling, parameters), we provide distinct mock objects: =
currently, just for the Servlet API and for JNDI. The only further =
candidate that I can think of at this point of time is the Portlet API.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Alef Arendsen
Gesendet: So 02.05.2004 16:18
An: spr...@li...
Betreff: RE: [Springframework-developer] Testing Controllers and =
FormControllers



> I'd still prefer a separate tree. More for clarity when users
> browse code. A lot of people are likely to look at the source
> in the /src tree and be confused as to why there's test-
> related stuff there that isn't in spring.jar.
+1

It will result in all kinds of questions popping up on the lists.

What about a separate module? Or did I miss the discussion there. It =
would
allow for separate development of the mock tree (and maybe other
test-related stuff). I imagine the amount of test-related supporting
features for 1.0.x to grow before 1.1 is released and people will be =
able to
use those enhancements as they are contained by separate releases (as
opposed to having them in the src or mock tree alongside the 1.0.x =
codebase
which might not be getting another release anymore).

A separate module does however result in more complexity and work when =
doing
releases and stuff maybe...

Alef
>
> Rgds,
> Rod
>
> ---- Original message ----
> >Date: Sun, 2 May 2004 13:26:29 +0200
> >From: j=FCrgen h=F6ller [werk3AT] <jue...@we...>
> >Subject: Re: [Springframework-developer] Testing Controllers
> and FormControllers
> >To: <spr...@li...>
> >
> >While I object to keeping our new mocks in the "test" tree,
> I'm not against keeping them in the "src" tree, excluding
> them from spring.jar and Clover coverage. Rod was quite keen
> on having the separate "mock" tree, so I guess we need to
> wait for his opinion, taking into account the Maven issue.
> Unfortunately, he won't be online before Tuesday morning...
> >
> >In any case, it's important to agree on this before 1.0.2,
> which is currently scheduled for release in two weeks.
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: spr...@li...
> im Auftrag von Luke Taylor
> >Gesendet: Fr 30.04.2004 21:44
> >An: spr...@li...
> >Betreff: Re: [Springframework-developer] Testing Controllers
> and FormControllers
> >
> >
> >
> >My main concern isn't so much whether they are in the test
> or src tree,
> >it's just that the overall structure seems a bit haphazard.
> And I don't
> >see why they should be split from the core when other
> modules aren't.
> >
> >If separate modules are going to be split from the codebase
> then it
> >would make sense to follow a standard pattern, e.g.
> >
> >core
> >  |
> >   - src
> >  |
> >   - test
> >
> >mock
> >  |
> >   - src
> >
> >other
> >  |
> >   - src
> >  |
> >   - test
> >
> >Ok, Ok... so my main concern is that it won't work with my
> Maven build
> >unless I hack it :) and until then my reports are stuck at
> Apr 28th. But
> >I agree with the aims Maven had of establishing a common
> structure for
> >project layouts, even though you could easily argue that
> they aren't
> >exactly a shining example of best practice development
> themselves.
> >
> >Luke.
> >
> >j=FCrgen h=F6ller [werk3AT] wrote:
> >> IMO, there's a strong difference between the "mock" and
> the "test"
> >> tree: The latter is a rough test suite for the framework
> itself,
> >> while the former contains polished mock classes that are
> also useful
> >> for applications, thus get distributed as "spring-
> mock.jar". The
> >> mocks would even fit better in "src" than in "test" in
> that respect.
> >>
> >> Actually, the "mock" tree is more similar to the
> main "src" tree than
> >> the "test" tree in a number of respects: It's meant to be
> used by
> >> applications, shipped as jar , included in the javadoc,
> and requires
> >> higher coding standards than the framework test suite. I'm
> quite
> >> strongly against keeping that sort of classes in
> the "test" tree.
> >>
> >> Juergen
> >>
> >>
> >
> >
> >
> >--
> >  Luke Taylor.                      Monkey Machine Ltd.
> >  PGP Key ID: 0x57E9523C
> http://www.monkeymachine.ltd.uk
> >
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: Oracle 10g
> >Get certified on the hottest thing ever to hit the market...
> Oracle 10g.
> >Take an Oracle 10g class now, and we'll give you the exam
> FREE.
> >http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
> >_______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
> >https://lists.sourceforge.net/lists/listinfo/springframework-
> developer
> >
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: Oracle 10g
> >Get certified on the hottest thing ever to hit the market...
> Oracle 10g.
> >Take an Oracle 10g class now, and we'll give you the exam
> FREE.
> >http://ads.osdn.com/?ad_id149&alloc_id=8166&op=C0ick
> >_______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
> >https://lists.sourceforge.net/lists/listinfo/springframework-
> developer
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Testing Controllers and FormControllers

[Alef A. <al...@jt...>]

> I'd still prefer a separate tree. More for clarity when users
> browse code. A lot of people are likely to look at the source
> in the /src tree and be confused as to why there's test-
> related stuff there that isn't in spring.jar.
+1

It will result in all kinds of questions popping up on the lists.

What about a separate module? Or did I miss the discussion there. It =
would
allow for separate development of the mock tree (and maybe other
test-related stuff). I imagine the amount of test-related supporting
features for 1.0.x to grow before 1.1 is released and people will be =
able to
use those enhancements as they are contained by separate releases (as
opposed to having them in the src or mock tree alongside the 1.0.x =
codebase
which might not be getting another release anymore).

A separate module does however result in more complexity and work when =
doing
releases and stuff maybe...

Alef
>=20
> Rgds,
> Rod
>=20
> ---- Original message ----
> >Date: Sun, 2 May 2004 13:26:29 +0200
> >From: j=FCrgen h=F6ller [werk3AT] <jue...@we...>
> >Subject: Re: [Springframework-developer] Testing Controllers
> and FormControllers
> >To: <spr...@li...>
> >
> >While I object to keeping our new mocks in the "test" tree,
> I'm not against keeping them in the "src" tree, excluding
> them from spring.jar and Clover coverage. Rod was quite keen
> on having the separate "mock" tree, so I guess we need to
> wait for his opinion, taking into account the Maven issue.
> Unfortunately, he won't be online before Tuesday morning...
> >
> >In any case, it's important to agree on this before 1.0.2,
> which is currently scheduled for release in two weeks.
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: spr...@li...
> im Auftrag von Luke Taylor
> >Gesendet: Fr 30.04.2004 21:44
> >An: spr...@li...
> >Betreff: Re: [Springframework-developer] Testing Controllers
> and FormControllers
> >
> >
> >
> >My main concern isn't so much whether they are in the test
> or src tree,
> >it's just that the overall structure seems a bit haphazard.
> And I don't
> >see why they should be split from the core when other
> modules aren't.
> >
> >If separate modules are going to be split from the codebase
> then it
> >would make sense to follow a standard pattern, e.g.
> >
> >core
> >  |
> >   - src
> >  |
> >   - test
> >
> >mock
> >  |
> >   - src
> >
> >other
> >  |
> >   - src
> >  |
> >   - test
> >
> >Ok, Ok... so my main concern is that it won't work with my
> Maven build
> >unless I hack it :) and until then my reports are stuck at
> Apr 28th. But
> >I agree with the aims Maven had of establishing a common
> structure for
> >project layouts, even though you could easily argue that
> they aren't
> >exactly a shining example of best practice development
> themselves.
> >
> >Luke.
> >
> >j=FCrgen h=F6ller [werk3AT] wrote:
> >> IMO, there's a strong difference between the "mock" and
> the "test"
> >> tree: The latter is a rough test suite for the framework
> itself,
> >> while the former contains polished mock classes that are
> also useful
> >> for applications, thus get distributed as "spring-
> mock.jar". The
> >> mocks would even fit better in "src" than in "test" in
> that respect.
> >>
> >> Actually, the "mock" tree is more similar to the
> main "src" tree than
> >> the "test" tree in a number of respects: It's meant to be
> used by
> >> applications, shipped as jar , included in the javadoc,
> and requires
> >> higher coding standards than the framework test suite. I'm
> quite
> >> strongly against keeping that sort of classes in
> the "test" tree.
> >>
> >> Juergen
> >>
> >>
> >
> >
> >
> >--
> >  Luke Taylor.                      Monkey Machine Ltd.
> >  PGP Key ID: 0x57E9523C
> http://www.monkeymachine.ltd.uk
> >
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: Oracle 10g
> >Get certified on the hottest thing ever to hit the market...
> Oracle 10g.
> >Take an Oracle 10g class now, and we'll give you the exam
> FREE.
> >http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
> >_______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
> >https://lists.sourceforge.net/lists/listinfo/springframework-
> developer
> >
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: Oracle 10g
> >Get certified on the hottest thing ever to hit the market...
> Oracle 10g.
> >Take an Oracle 10g class now, and we'll give you the exam
> FREE.
> >http://ads.osdn.com/?ad_id149&alloc_id=8166&op=C0ick
> >_______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
> >https://lists.sourceforge.net/lists/listinfo/springframework-
> developer
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Testing Controllers and FormControllers

[Rod J. <rod...@in...>]

I'd still prefer a separate tree. More for clarity when users =

browse code. A lot of people are likely to look at the source =

in the /src tree and be confused as to why there's test-
related stuff =
there that isn't in spring.jar.

Rgds,
Rod

---- Original message -=
---
>Date: Sun, 2 May 2004 13:26:29 +0200
>From: j=FCrgen h=F6ller [we=
rk3AT] <jue...@we...>  =

>Subject: Re: [Springframework-developer] Testing Controllers =

and FormControllers  =

>To: <spr...@li...>
>
>While I obje=
ct to keeping our new mocks in the "test" tree, =

I'm not against keeping them in the "src" tree, excluding =

them from spring.jar and Clover coverage. Rod was quite keen =

on having the separate "mock" tree, so I guess we need to =

wait for his opinion, taking into account the Maven issue. =

Unfortunately, he won't be online before Tuesday morning...
> =

>In any case, it's important to agree on this before 1.0.2, =

which is currently scheduled for release in two weeks.
> =

>Juergen
> =

>
>________________________________
>
>Von: springframework-developer=
-ad...@li... =

im Auftrag von Luke Taylor
>Gesendet: Fr 30.04.2004 21:44
>An: springf=
ram...@li...
>Betreff: Re: [Springframework=
-developer] Testing Controllers =

and FormControllers
>
>
>
>My main concern isn't so much whether the=
y are in the test =

or src tree,
>it's just that the overall structure seems a bit haphazar=
d. =

And I don't
>see why they should be split from the core when other =

modules aren't.
>
>If separate modules are going to be split from the =
codebase =

then it
>would make sense to follow a standard pattern, e.g.
>
>core
>  |
>   - src
>  |
>   - test
>
>mock
>  |
>   - src
>
>other
>  |
>   - src
>  |
>   - test
>
>Ok, Ok... so my main concern is t=
hat it won't work with my =

Maven build
>unless I hack it :) and until then my reports are stuck at=
 =

Apr 28th. But
>I agree with the aims Maven had of establishing a common=
 =

structure for
>project layouts, even though you could easily argue that=
 =

they aren't
>exactly a shining example of best practice development =

themselves.
>
>Luke.
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>> IMO, =
there's a strong difference between the "mock" and =

the "test"
>> tree: The latter is a rough test suite for the framework =
=

itself,
>> while the former contains polished mock classes that are =

also useful
>> for applications, thus get distributed as "spring-
mock=
.jar". The
>> mocks would even fit better in "src" than in "test" in =

that respect.
>>
>> Actually, the "mock" tree is more similar to the 
main "src" tree than
>> the "test" tree in a number of respects: It's m=
eant to be =

used by
>> applications, shipped as jar , included in the javadoc, =

and requires
>> higher coding standards than the framework test suite. =
I'm =

quite
>> strongly against keeping that sort of classes in =

the "test" tree.
>>
>> Juergen
>>
>>
>
>
>
>--
>  Luke Taylor. =
                     Monkey Machine Ltd.
>  PGP Key ID: 0x57E9523C     =
       =

http://www.monkeymachine.ltd.uk
>
>
>
>
>--------------------------=
-----------------------------
>This SF.Net email is sponsored by: Oracl=
e 10g
>Get certified on the hottest thing ever to hit the market... =

Oracle 10g.
>Take an Oracle 10g class now, and we'll give you the exam =
=

FREE.
>http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
>_=
______________________________________________
>Springframework-develop=
er mailing list
>Spr...@li...
>http=
s://lists.sourceforge.net/lists/listinfo/springframework-
developer
>
>
>
>
>-------------------------------------------------------
>This=
 SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest=
 thing ever to hit the market... =

Oracle 10g. =

>Take an Oracle 10g class now, and we'll give you the exam =

FREE. =

>http://ads.osdn.com/?ad_id149&alloc_id=8166&op=C0ick
>________________=
_______________________________
>Springframework-developer mailing list=

>Spr...@li...
>https://lists.sourc=
eforge.net/lists/listinfo/springframework-
developer

Re: [Springframework-developer] Testing Controllers and FormControllers

[<jue...@we...>]

While I object to keeping our new mocks in the "test" tree, I'm not =
against keeping them in the "src" tree, excluding them from spring.jar =
and Clover coverage. Rod was quite keen on having the separate "mock" =
tree, so I guess we need to wait for his opinion, taking into account =
the Maven issue. Unfortunately, he won't be online before Tuesday =
morning...
=20
In any case, it's important to agree on this before 1.0.2, which is =
currently scheduled for release in two weeks.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Luke Taylor
Gesendet: Fr 30.04.2004 21:44
An: spr...@li...
Betreff: Re: [Springframework-developer] Testing Controllers and =
FormControllers



My main concern isn't so much whether they are in the test or src tree,
it's just that the overall structure seems a bit haphazard. And I don't
see why they should be split from the core when other modules aren't.

If separate modules are going to be split from the codebase then it
would make sense to follow a standard pattern, e.g.

core
  |
   - src
  |
   - test

mock
  |
   - src

other
  |
   - src
  |
   - test

Ok, Ok... so my main concern is that it won't work with my Maven build
unless I hack it :) and until then my reports are stuck at Apr 28th. But
I agree with the aims Maven had of establishing a common structure for
project layouts, even though you could easily argue that they aren't
exactly a shining example of best practice development themselves.

Luke.

j=FCrgen h=F6ller [werk3AT] wrote:
> IMO, there's a strong difference between the "mock" and the "test"
> tree: The latter is a rough test suite for the framework itself,
> while the former contains polished mock classes that are also useful
> for applications, thus get distributed as "spring-mock.jar". The
> mocks would even fit better in "src" than in "test" in that respect.
>
> Actually, the "mock" tree is more similar to the main "src" tree than
> the "test" tree in a number of respects: It's meant to be used by
> applications, shipped as jar , included in the javadoc, and requires
> higher coding standards than the framework test suite. I'm quite
> strongly against keeping that sort of classes in the "test" tree.
>
> Juergen
>
>



--
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] minor annoyances

[<jue...@we...>]

Tom,
=20
I've just addressed your AbstractWizardFormController issues: =
validatePagesAndFinish checks for page-specific binding errors now, and =
getCurrentPage allows to retrieve the current page at any point in =
request processing. So processFinish still doesn't have a page =
parameter, but you can now invoke getCurrentPage from there.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Tom Turelinckx
Gesendet: Mi 28.04.2004 09:38
An: spr...@li...
Betreff: [Springframework-developer] minor annoyances



Hello,

While upgrading to spring 1.0.1, I've noticed some minor annoyances that
may be easy to fix, possibly for 1.0.2:

1. HttpServletBean apparently does not support properties of type
Resource, because BeanWrapperImpl does not register a Resource property
editor by default. However, there's no possibility to register custom
editors with the BeanWrapper used by HttpServletBean. Maybe an
"initBeanWrapper" protected method could be added here, like initBinder
in BaseCommandController?

2. Unlike ResourceBundleMessageSource, ResourceBundleViewResolver only
has a basename property, no basenames property. As we keep controller
cfg, dao cfg and messages in separate resource files by functional
domain, it also makes sense to keep the view cfg in different files.
We're currently using an adapted ResourceBundleViewResolver, but maybe
this functionality could be added to spring, or maybe there's a good
reason to keep all view cfg in a single file?

3. In AbstractWizardFormController, it would be useful if processFinish
had an extra "int submissionPage" parameter (the currentPage value in
processFormSubmission could be passed to validatePagesAndFinish and on =
to
processFinish), though I have no suggestion how to add this in a
backward-compatible way...
It would be useful, because some of our legacy stored procedures perform
validation logic that we can't duplicate in java, i.e. the result of a
stored procedure could indicate a user-correctable error, which we would
like to display in the same way as a global validation error, e.g.:

protected ModelAndView processFinish( HttpServletRequest request,
        HttpServletResponse response, Object command,
        BindException errors, int page ) throws Exception {
    // stored procedure is called in onSubmit,
    // messageInfo is an output parameter
    MessageInfo messageInfo =3D onSubmit( command );
    if ( messageInfo.isError() ) {
        errors.reject( "", messageInfo.getMessage() );
        return showPage( request, errors, page );
    }
    if ( messageInfo.isWarning() ) {
        return handleWarning( command, messageInfo );
    }
    return handleSuccess( command, messageInfo );
}

Note that getCurrentPage can't be called in processFinish, as we are
"after processFormSubmission".

Even if the page parameter can't be added to processFinish, it would
still be useful to add it to validatePagesAndFinish:

private ModelAndView validatePagesAndFinish(HttpServletRequest request,
        HttpServletResponse response, Object command,
        BindException errors, int currentPage) throws Exception {

    // in case of binding errors  -> show current page
    if (errors.getErrorCount() - errors.getGlobalErrorCount() > 0) {
        return showPage(request, errors, currentPage);
    }

    for (int page =3D 0; page < pages.length; page++) {
        validatePage(command, errors, page);
        // in case of field errors on a page -> show the page
        if (errors.getErrorCount() - errors.getGlobalErrorCount() > 0) {
            return showPage(request, errors, page);
        }
    }
    // no field errors -> maybe global errors, or none at all
    return processFinish(request, response, command, errors,
    currentPage);
}

The first if was added to ensure the current page is shown again if =
there
were binding errors, such as typeMismatch. Otherwise, those errors will
always result in the first page being shown, instead of the submission
page where the error actually occured.

Also, shouldn't the "if (pages =3D=3D null | pages.length =3D=3D 0)" in =
setPages
use "||" instead of "|"?

Kind regards,
Tom.


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring Portlet MVC layer is rendering JSTL Views!!!

[William G. T. Jr. <wg...@ru...>]

Folks,

I have packaged up a Portlet Application that may be of interest.  The 
war file is available at:
   http://www.tnt-web.com/springportlet/springportlet.war

You should be able to download the war file and then deploy using the 
tools for whatever portlet container you are using.  I'm running this 
with uPortal2.3 which embeds Pluto.


There are two portlets defined in WEB-INF/portlet.xml

1) InspectPortlet - a "fat" portlet that displays various bits of info 
available through the Portlet API (built using only GenericPortlet)

2) ExampleSpringPortlet - proof-of-concept portlet built using Spring 
MVC layer adapted for the Portlet API.  The portlet name maps to a 
DispatcherPortlet which bootstraps:
   a) applicationContext.xml - the root PortletApplicationContext
   b) ExampleSpringPortlet-portlet.xml - config for the named 
DispatcherPortlet (handler mappings, view resolvers, controllers, etc.)

As configured, ExampleSpringPortlet simply maps PortletModes to view 
names and finally dispatches to JSPs:
   WEB-INF/jsp/portlet/view.jsp
   WEB-INF/jsp/portlet/edit.jsp
   WEB-INF/jsp/portlet/help.jsp

The Portlet API defines a tag-lib as well and I use that to generate the 
RenderURLs you will see in the views.

later.
Bill

ps.  If you are using uPortal2.3 here are the deploy steps:
1) ant deployPortletApp -DportletApp=/path/to/springportlet.war
2) bounce tomcat
3) using the Channel Manager define two new Portlet Channels.  The 
portlet Ids are:
   springportlet.InspectPortlet
   springportlet.ExampleSpringPortlet

Re: [Springframework-developer] Spring Portlet MVC layer is rendering JSTL Views!!!

[William G. T. Jr. <wg...@ru...>]

the initial drop of o.s.w.portlet.* is now in the sandbox.  it still 
needs work, but it is doing the following:
* initialize applicationContext.xml
* initialize {portletName}-portlet.xml
* implements Spring Portlet MVC via DispatchPortlet
* can render views with o.s.w.portlet.view.JSTLView

I'll package up a SampleSpringPortlet.war shortly so you can deploy it 
and play.

later.
Bill


Alexi Polenur wrote:
> Hi,
> 
> Do you have any examples on how to use new portlet package ?
> 
> Thanks a lot, Alexi
> 
> William G. Thompson, Jr. wrote:
> 
>> Les A. Hazlewood wrote:
>>
>>> I think this is just great.  Any idea of when others can take a look 
>>> at the
>>> code?
>>
>>
>>
>> I am hoping we can get it into the sandbox soon.  I can also put up a 
>> jar at a URL you can snarf later today.
>>
>>>
>>> Thanks for heading the effort Bill :)
>>
>>
>>
>> No problem...it was nice to dig into the internals of Spring...anyway 
>> we need this badly as we are about to start a major Portlet dev cycle 
>> for myRutgers.
>>
>>>
>>> Regards,
>>>
>>> Les
>>>
>>> P.S.  Since code has been somewhat replicated in places, what does 
>>> this mean for
>>> long term maintenance for the two packages (i.e. o.s.w.servlet.* and
>>> o.s.w.portlet.*)?  What kind of synchronization efforts would be 
>>> required, if
>>> any?
>>
>>
>>
>> The MVC architecture is essentially the same and the Portlet API 
>> somewhat mirrors the Servlet API.  However there are enough 
>> differences that made it necessary to have the seperate package.
>>
>> It is a testament to the Spring architecture that every time there was 
>> dependancy outside of o.s.w.servlet.* I could reuse that code without 
>> any modification.
>>
>>
>>>
>>> Quoting "William G. Thompson, Jr." <wg...@ru...>:
>>>
>>>
>>>> Folks,
>>>>
>>>> Spring Portlet MVC layer is rendering JSTL Views with full
>>>> ApplicationContext support!!!
>>>>
>>>> I ended having to port just about the entire
>>>> org.springframework.web.servlet.* package.
>>>>
>>>> Should this go into the sandbox?  I suspect that it may still need some
>>>> refactoring...after we play with it a bit more.
>>>>
>>>> later.
>>>> Bill
>>>
>>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: Oracle 10g
>> Get certified on the hottest thing ever to hit the market... Oracle 
>> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. 
>> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE. 
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] [Commons Validator] Messages not resolved [solved]

[Alef A. <al...@jt...>]

Matt,

This is the default behavior the MessageFormat shows. Have a look at the
JavaDoc for java.text.MessageFormat and you'll see that if you're using
''{0}'', it'll work (so two quotes instead of just one).

I'm not sure how Commons validator does replacements of arguments, but I
guess it isn't using the MessageFormat class then...

Alef


> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of Matt Raible
> Sent: Friday, April 30, 2004 8:34 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] [Commons Validator] Messages =
not
> resolved [solved]
>=20
> There's nothing like banging your head against the wall trying to =
figure
> something out.
>=20
> The issue turned out to be that my ApplicationResources file had =
single
> quotes for validation error messages:
>=20
> errors.invalid=3D'{0}' is invalid.
>=20
> I had to change it to:
>=20
> errors.invalid=3D{0} is invalid.
>=20
> Then everything worked as desired.  So, in short, using Commons
> Validator with Struts allows this, but using it with Spring does not.
> It's easy enough to remove the quotes - but this should probably be
> fixed and/or documented.
>=20
> Matt
>=20
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]
> >  On Behalf Of Matt Raible
> > Sent: Friday, April 30, 2004 4:23 AM
> > To: spr...@li...
> > Subject: [Springframework-developer] [Commons Validator]
> > Messages not resolved
> >
> >
> > I have two apps - one is based on Servlet 2.4 and one on 2.3.
> >  From what I can tell, all the configuration is the same for
> > commons validator. I'm certain that the JARs are the same on
> > both projects.  Now I'm having a really strange problem.  On
> > the 2.4 project (done with an XSD in web.xml), the messages
> > resolve fine, so if lastName is required, I get "Last Name is
> > a required field."  If I try the same thing on the 2.3
> > project, I get "{0} is a required field."  Everything looks
> > right for JSTL and all my other messages are getting resolved
> > - except for messages from the validation engine.  I've
> > pasted my relevant config below.  I tried manipulating the
> > 2.3/2.4 thing too - that didn't help.
> >
> > Another difference b/w the 2 projects is one uses
> > org.springframework.web.servlet.view.JstlView and the 2nd
> > (non-working) one uses TilesJstlView.
> >
> > I'm using the latest stuff from CVS.
> >
> > Thanks,
> >
> > Matt
> >
> >     <bean id=3D"userFormController"
> > class=3D"org.appfuse.webapp.action.UserFormController">
> >         ...
> >         <property name=3D"validator"><ref
> > bean=3D"beanValidator"/></property>
> >         ...
> >     </bean>
> >
> >     <!-- This file is really named
> > ApplicationResources_en.properties to JSTL will pick
> >          it up as the default. I know it doesn't sound right,
> > but it works.  I tried
> >          renaming w/o the extension, no dice. -->
> >     <bean id=3D"messageSource"
> >
> > class=3D"org.springframework.context.support.ResourceBundleMessa
> > geSource">
> >         <property
> > name=3D"basename"><value>ApplicationResources</value></property>
> >     </bean>
> >
> >     <bean id=3D"validatorFactory"
> > class=3D"org.springframework.validation.commons.DefaultValidator
> > Factory"
> >         init-method=3D"init">
> > 		<property name=3D"resources">
> >             <list>
> >                 <value>WEB-INF/validation.xml</value>
> >                 <value>WEB-INF/validator-rules.xml</value>
> >                 <value>WEB-INF/validator-rules-custom.xml</value>
> >             </list>
> > 		</property>
> > 	</bean>
> >
> > 	<bean id=3D"beanValidator"
> > class=3D"org.springframework.validation.commons.BeanValidator">
> > 		<property name=3D"validatorFactory"><ref
> > local=3D"validatorFactory"/></property>
> > 	</bean>
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: Oracle 10g
> > Get certified on the hottest thing ever to hit the market...
> > Oracle 10g.
> > Take an Oracle 10g class now, and we'll give you the exam FREE.
> > http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Testing Controllers and FormControllers

[Luke T. <ne...@fr...>]

My main concern isn't so much whether they are in the test or src tree, 
it's just that the overall structure seems a bit haphazard. And I don't 
see why they should be split from the core when other modules aren't.

If separate modules are going to be split from the codebase then it 
would make sense to follow a standard pattern, e.g.

core
  |
   - src
  |
   - test

mock
  |
   - src

other
  |
   - src
  |
   - test

Ok, Ok... so my main concern is that it won't work with my Maven build 
unless I hack it :) and until then my reports are stuck at Apr 28th. But 
I agree with the aims Maven had of establishing a common structure for 
project layouts, even though you could easily argue that they aren't 
exactly a shining example of best practice development themselves.

Luke.

jürgen höller [werk3AT] wrote:
> IMO, there's a strong difference between the "mock" and the "test"
> tree: The latter is a rough test suite for the framework itself,
> while the former contains polished mock classes that are also useful
> for applications, thus get distributed as "spring-mock.jar". The
> mocks would even fit better in "src" than in "test" in that respect.
> 
> Actually, the "mock" tree is more similar to the main "src" tree than
> the "test" tree in a number of respects: It's meant to be used by
> applications, shipped as jar , included in the javadoc, and requires
> higher coding standards than the framework test suite. I'm quite
> strongly against keeping that sort of classes in the "test" tree.
> 
> Juergen
> 
> 



-- 
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk

RE: [Springframework-developer] [Commons Validator] Messages not resolved [solved]

[Matt R. <li...@ra...>]

There's nothing like banging your head against the wall trying to figure
something out.

The issue turned out to be that my ApplicationResources file had single
quotes for validation error messages:

errors.invalid='{0}' is invalid.

I had to change it to:

errors.invalid={0} is invalid.

Then everything worked as desired.  So, in short, using Commons
Validator with Struts allows this, but using it with Spring does not.
It's easy enough to remove the quotes - but this should probably be
fixed and/or documented.

Matt

> -----Original Message-----
> From: spr...@li... 
> [mailto:spr...@li...]
>  On Behalf Of Matt Raible
> Sent: Friday, April 30, 2004 4:23 AM
> To: spr...@li...
> Subject: [Springframework-developer] [Commons Validator] 
> Messages not resolved
> 
> 
> I have two apps - one is based on Servlet 2.4 and one on 2.3. 
>  From what I can tell, all the configuration is the same for 
> commons validator. I'm certain that the JARs are the same on 
> both projects.  Now I'm having a really strange problem.  On 
> the 2.4 project (done with an XSD in web.xml), the messages 
> resolve fine, so if lastName is required, I get "Last Name is 
> a required field."  If I try the same thing on the 2.3 
> project, I get "{0} is a required field."  Everything looks 
> right for JSTL and all my other messages are getting resolved 
> - except for messages from the validation engine.  I've 
> pasted my relevant config below.  I tried manipulating the 
> 2.3/2.4 thing too - that didn't help.
> 
> Another difference b/w the 2 projects is one uses 
> org.springframework.web.servlet.view.JstlView and the 2nd 
> (non-working) one uses TilesJstlView.
> 
> I'm using the latest stuff from CVS.
> 
> Thanks,
> 
> Matt
> 
>     <bean id="userFormController" 
> class="org.appfuse.webapp.action.UserFormController">
>         ...
>         <property name="validator"><ref 
> bean="beanValidator"/></property>
>         ...
>     </bean>
> 
>     <!-- This file is really named 
> ApplicationResources_en.properties to JSTL will pick 
>          it up as the default. I know it doesn't sound right, 
> but it works.  I tried 
>          renaming w/o the extension, no dice. -->
>     <bean id="messageSource" 
>  
> class="org.springframework.context.support.ResourceBundleMessa
> geSource">
>         <property 
> name="basename"><value>ApplicationResources</value></property>
>     </bean>
> 
>     <bean id="validatorFactory" 
> class="org.springframework.validation.commons.DefaultValidator
> Factory" 
>         init-method="init">
> 		<property name="resources">
>             <list>
>                 <value>WEB-INF/validation.xml</value>
>                 <value>WEB-INF/validator-rules.xml</value>
>                 <value>WEB-INF/validator-rules-custom.xml</value>
>             </list>
> 		</property>
> 	</bean>
> 
> 	<bean id="beanValidator" 
> class="org.springframework.validation.commons.BeanValidator">
> 		<property name="validatorFactory"><ref 
> local="validatorFactory"/></property>
> 	</bean>
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... 
> Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE. 
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: Rr: [Springframework-developer] Why is TransactionProxyFactoryBean forced to be singleton

[Colin S. <col...@ex...>]

Ok, (on looking at the logs) I just realized that for prototype target=20
beans, BeanNameAutoProxyCreator is applied to the prototype after it's=20
created, so in fact BeanNameAutoProxyCreator is immediately usable with=20
prototypes. I had not know that BeanNameAutoProxyCreator was applied at=20
all to prototype beans.

So this works. My only concern is that it's not incrredibly efficient if=20
you have a bunch of these BeanPostProcessors registered on prototypes=20
like this, as compared to the alternative mentioned below. However, the=20
alternative mentioned below is not implementable anyways, since at=20
container startup there won't be any instance of the prototype bean for=20
the postprocessor to work with. You would really have to do this with a=20
BeanFactoryPostProcessor instead of a BeanPostProcessor.

Regards,
Colin


Colin Sampaleanu wrote:

> Actually, it looks like all that would be needed to do is set a=20
> prototype target source creator of some sort into the=20
> CustomTargetSourceCreators list. Now there is no non-abstract=20
> prototype target source creator that people can use, and even if there=20
> was, it's somewhat of a pain for people to create one just for this=20
> purpose. Does it make sense to have BeanNameAutoProxy creator by=20
> default register a prototype custom target source creator? (it could=20
> still be overriden of course). If you think about it, the current=20
> default BeanNameAutoProxy creator default behaviour is wrong anyways=20
> in the face of wrapping prototype beans, since it will generate a=20
> singleton proxy around just one instance from the prototype bean that=20
> is being wrapped, instead of ensuring a prototype is returned each time=
.
>
> Regards,
> Colin
>
> Colin Sampaleanu wrote:
>
>> I'm not 100% sure I agree. At a minimum, we need to document this as=20
>> an alternative to TransactionProxyFactoryBean, since I think a lot of=20
>> people just using examples won't realize they can do it. But even=20
>> then, it's a fair bit more verbose than TransactionProxyFactoryBean,=20
>> which is also a lot more verbose than using BeanNameAutoProxyCreator=20
>> on a bunch of beans with the same basic handling.
>>
>> One addition which would cover some cases is enhancing=20
>> BeanNameAutoProxyCreator, or creating some variant of it, so that it=20
>> can work in a prototype fashion. So when working in prototype mode,=20
>> what it produces and stuffs back in the context is a prototype=20
>> (isSingleton=3Dfalse) ProxyFactoryBean instance, effectively the same=20
>> as if the user had used the basic ProxyFactoryBean to do=20
>> transactional interception, in non-singleton fashion.
>>
>> What do you think?
>>
>> Regards,
>> Colin
>>
>> j=FCrgen h=F6ller [werk3AT] wrote:
>>
>>> Wrapping prototypes with transactional proxies should work nicely=20
>>> when using ProxyFactoryBean plus TransactionInterceptor. The target=20
>>> there is just a bean name, not a bean reference - so this will work=20
>>> with a prototype, despite the FactoryBean being a singleton.
>>>
>>> TransactionProxyFactoryBean is essentially a convenience class=20
>>> that's really meant to be used for the typical case of singleton=20
>>> targets, referring to them via a bean reference. I'd prefer to leave=20
>>> it that way, recommending ProxyFactoryBean plus=20
>>> TransactionInterceptor for prototypes.
>>>
>>> Juergen
>>>
>>>
>>> -----Original Message-----
>>> From: spr...@li...
>>> [mailto:spr...@li...]On Beha=
lf
>>> Of Colin Sampaleanu
>>> Sent: Friday, April 30, 2004 2:20 PM
>>> To: spr...@li...
>>> Subject: Re: [Springframework-developer] Why is
>>> TransactionProxyFactoryBean forced to be singleton
>>>
>>>
>>> The nasty thing is that while it is relatively easy to make=20
>>> TransactionProxyFactoryBean non-singleton in the sense that it=20
>>> respects its internal 'singleton' property and generates a new proxy=20
>>> on each getObject() call if non-singleton, this is effectively=20
>>> useless since it will be operating on the same target, and the=20
>>> container will only give it the target once since all FactoryBeans=20
>>> are singletons unless the container gives it a new target each time,=20
>>> which currently there is no way to make happen since currently=20
>>> factorybean objects themselves have to be singleton in terms of the=20
>>> container and are only populated once. For this to work, the=20
>>> factorybean has to be a prototype, and the target has to be a=20
>>> prototype.
>>>
>>> While wrapping stateful objects like this is not as common as=20
>>> wrapping stateless objects, it's something we should be able to=20
>>> support.
>>>
>>> Can anybody see a simple way to do this, before we start mucking=20
>>> around with basic container behaviour (i.e. forced singleton status=20
>>> of factorybeans).?
>>>
>>> Regards,
>>> Colin
>>>
>>>
>>> Colin Sampaleanu wrote:
>>>
>>> =20
>>>
>>>> I just realized that TransactionProxyFactoryBean always returns=20
>>>> true for ProxyFactoryBean's the isSingleton() method, and=20
>>>> internally does not support non-singleton operation, since it only=20
>>>> sets up the proxy once in afterPropertiesSet().
>>>>
>>>> I have a case where a client of the beanfactory is using=20
>>>> bf.getBean("xxx"), and needs to get back a new transactionally=20
>>>> wrapped instance on every call, sine the object is stateful, unlike=20
>>>> every other service I've wrapped transactionally so far.
>>>>
>>>> Does anybody know why the class was set up to operate in singleton=20
>>>> mode only? It makes sense as a default of course, but I can't see=20
>>>> anything in the code precluding allowing it to operate in=20
>>>> non-singleton mode as well, if things were moved around a bit...
>>>>   =20
>>>
>>>
>
>

Re: [Springframework-developer] Spring Portlet MVC layer is rendering JSTL Views!!!

[Alexi P. <apo...@ya...>]

Hi,

Do you have any examples on how to use new portlet package ?

Thanks a lot, Alexi

William G. Thompson, Jr. wrote:

> Les A. Hazlewood wrote:
>
>> I think this is just great.  Any idea of when others can take a look 
>> at the
>> code?
>
>
> I am hoping we can get it into the sandbox soon.  I can also put up a 
> jar at a URL you can snarf later today.
>
>>
>> Thanks for heading the effort Bill :)
>
>
> No problem...it was nice to dig into the internals of Spring...anyway 
> we need this badly as we are about to start a major Portlet dev cycle 
> for myRutgers.
>
>>
>> Regards,
>>
>> Les
>>
>> P.S.  Since code has been somewhat replicated in places, what does 
>> this mean for
>> long term maintenance for the two packages (i.e. o.s.w.servlet.* and
>> o.s.w.portlet.*)?  What kind of synchronization efforts would be 
>> required, if
>> any?
>
>
> The MVC architecture is essentially the same and the Portlet API 
> somewhat mirrors the Servlet API.  However there are enough 
> differences that made it necessary to have the seperate package.
>
> It is a testament to the Spring architecture that every time there was 
> dependancy outside of o.s.w.servlet.* I could reuse that code without 
> any modification.
>
>
>>
>> Quoting "William G. Thompson, Jr." <wg...@ru...>:
>>
>>
>>> Folks,
>>>
>>> Spring Portlet MVC layer is rendering JSTL Views with full
>>> ApplicationContext support!!!
>>>
>>> I ended having to port just about the entire
>>> org.springframework.web.servlet.* package.
>>>
>>> Should this go into the sandbox?  I suspect that it may still need some
>>> refactoring...after we play with it a bit more.
>>>
>>> later.
>>> Bill
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 
> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. 
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>