springframework-developer — Spring Framework developers list

[Springframework-developer] java.sql.SQLException: E/A-Exception: Software caused connection abort: socket write error

[Sebastian S. <seb...@op...>]

I used in my project the code from the storeImage method in imagedb sample.
Trying to insert a Blob to my a Oracle9i DB i get this:

Any ideas what this means?

Regards,
Sebastian

WARN [org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator] -
<Unable to translate SQLException with errorCode '17002', will now try the
fallback translator>
INFO [org.springframework.jdbc.support.SQLStateSQLExceptionTranslator] -
<Translating SQLException with SQLState 'null' and errorCode '17002' and
message [E/A-Exception: Software caused connection abort: socket write
error]; SQL was [INSERT INTO productdb (productId, content, filename) VALUES
(?, ?, ?)] for task [storeProductContent]>
WARN [org.springframework.jdbc.support.JdbcUtils] - <Could not close JDBC
Statement>

java.sql.SQLException: E/A-Exception: Software caused connection abort:
socket write error
	at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
	at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:179)
	at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:334)
	at oracle.jdbc.driver.OracleConnection.commit(OracleConnection.java:1381)
	at
org.springframework.jdbc.datasource.DataSourceTransactionManager.doCommit(Da
taSourceTransactionManager.java:211)
	at
org.springframework.transaction.support.AbstractPlatformTransactionManager.c
ommit(AbstractPlatformTransactionManager.java:314)

Re: AW: [Springframework-developer] (MultipartHttpServletRequest) request ClassCastException

[<bro...@ya...>]

:-) glad to have provided the key 

--- Sebastian Szczygiel <seb...@op...> wrote: >
I have, that wasn't the problem, but you guided me
> to the bug. I tried to
> use my Controller for all request, even
> non-multipart http-request. Stupid.
> 
> Thank you,
> Sebastian
> 
> 
> -----Ursprüngliche Nachricht-----
> Von:
>
spr...@li...
>
[mailto:spr...@li...]Im
> Auftrag
> von Bronwen Cassidy
> Gesendet: Mittwoch, 5. Mai 2004 18:00
> An: spr...@li...
> Betreff: Re: [Springframework-developer]
> (MultipartHttpServletRequest)
> request ClassCastException
> 
> 
> Hi Sebastian,
> 
> Do you have this: encType="multipart/form-data" in
> your form tag??
> 
> --- Sebastian Szczygiel <seb...@op...> wrote:
> >
> Hello,
> >
> > inside a simple Spring-Controller i try this:
> >
> > public ModelAndView
> handleRequest(HttpServletRequest
> > request,
> > HttpServletResponse response) throws
> > ServletException, IOException {
> > ...
> > MultipartHttpServletRequest multipartRequest =
> > (MultipartHttpServletRequest)
> > request;
> > ...
> >
> > Buy at (MultipartHttpServletRequest) request i get
> a
> > ClassCastException,
> > why?
> > The MultipartResolver is loaded correctly. For
> this
> > i use the following line
> > in my application context XML:
> >
> >   <bean id="multipartResolver"
> >
>
class="org.springframework.web.multipart.commons.CommonsMultipartResolver"/>
> >
> > Lob Handler and so on is also defined in the XML.
> I
> > looked at the imagedb
> > example but can't find the problem in my code.
> >
> > Regards,
> > Sebastian
> >
> >
> >
> >
> >
>
-------------------------------------------------------
> > 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
> 
> 
> 
> 
> 
>
____________________________________________________________
> Yahoo! Messenger - Communicate instantly..."Ping"
> your friends today! Download Messenger Now
> http://uk.messenger.yahoo.com/download/index.html
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson
> & Lucent use to
> deliver higher performing products faster, at low
> TCO.
>
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson
> & Lucent use to 
> deliver higher performing products faster, at low
> TCO.
>
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer 


	
	
		
____________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

AW: [Springframework-developer] (MultipartHttpServletRequest) request ClassCastException

[Sebastian S. <seb...@op...>]

I have, that wasn't the problem, but you guided me to the bug. I tried to
use my Controller for all request, even non-multipart http-request. Stupid.

Thank you,
Sebastian


-----Ursprüngliche Nachricht-----
Von: spr...@li...
[mailto:spr...@li...]Im Auftrag
von Bronwen Cassidy
Gesendet: Mittwoch, 5. Mai 2004 18:00
An: spr...@li...
Betreff: Re: [Springframework-developer] (MultipartHttpServletRequest)
request ClassCastException


Hi Sebastian,

Do you have this: encType="multipart/form-data" in
your form tag??

--- Sebastian Szczygiel <seb...@op...> wrote: >
Hello,
>
> inside a simple Spring-Controller i try this:
>
> public ModelAndView handleRequest(HttpServletRequest
> request,
> HttpServletResponse response) throws
> ServletException, IOException {
> ...
> MultipartHttpServletRequest multipartRequest =
> (MultipartHttpServletRequest)
> request;
> ...
>
> Buy at (MultipartHttpServletRequest) request i get a
> ClassCastException,
> why?
> The MultipartResolver is loaded correctly. For this
> i use the following line
> in my application context XML:
>
>   <bean id="multipartResolver"
>
class="org.springframework.web.multipart.commons.CommonsMultipartResolver"/>
>
> Lob Handler and so on is also defined in the XML. I
> looked at the imagedb
> example but can't find the problem in my code.
>
> Regards,
> Sebastian
>
>
>
>
>
-------------------------------------------------------
> 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





____________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] (MultipartHttpServletRequest) request ClassCastException

[<bro...@ya...>]

Hi Sebastian,

Do you have this: encType="multipart/form-data" in
your form tag?? 

--- Sebastian Szczygiel <seb...@op...> wrote: >
Hello,
> 
> inside a simple Spring-Controller i try this:
> 
> public ModelAndView handleRequest(HttpServletRequest
> request,
> HttpServletResponse response) throws
> ServletException, IOException {
> ...
> MultipartHttpServletRequest multipartRequest =
> (MultipartHttpServletRequest)
> request;
> ...
> 
> Buy at (MultipartHttpServletRequest) request i get a
> ClassCastException,
> why?
> The MultipartResolver is loaded correctly. For this
> i use the following line
> in my application context XML:
> 
>   <bean id="multipartResolver"
>
class="org.springframework.web.multipart.commons.CommonsMultipartResolver"/>
> 
> Lob Handler and so on is also defined in the XML. I
> looked at the imagedb
> example but can't find the problem in my code.
> 
> Regards,
> Sebastian
> 
> 
> 
> 
>
-------------------------------------------------------
> 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 


	
	
		
____________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

[Springframework-developer] (MultipartHttpServletRequest) request ClassCastException

[Sebastian S. <seb...@op...>]

Hello,

inside a simple Spring-Controller i try this:

public ModelAndView handleRequest(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
...
MultipartHttpServletRequest multipartRequest = (MultipartHttpServletRequest)
request;
...

Buy at (MultipartHttpServletRequest) request i get a ClassCastException,
why?
The MultipartResolver is loaded correctly. For this i use the following line
in my application context XML:

  <bean id="multipartResolver"
class="org.springframework.web.multipart.commons.CommonsMultipartResolver"/>

Lob Handler and so on is also defined in the XML. I looked at the imagedb
example but can't find the problem in my code.

Regards,
Sebastian

[Springframework-developer] confusion in jpetstore sample

[Hunter K. <re...@ei...>]

Hi there, I'm plowing through the wonderful world of SOAP, Jax-RPC, Axis, etc.

I was looking at the sample server-deploy.wsdd in 
samples/jpetstore/war/WEB-INF/server-config.wsdd, and come across the 
following:

 <service name="OrderService" provider="java:RPC">
  <parameter name="allowedMethods" value="*"/>
  <parameter name="className" 
value="org.springframework.samples.jpetstore.service.server.JaxRpcOrde
rService"/>
        <beanMapping qname="jpetstore:Order" xmlns:jpetstore="urn:BeanService" 
languageSpecificType=
"java:org.springframework.samples.jpetstore.domain.Order"/>
        <beanMapping qname="jpetstore:LineItem" 
xmlns:jpetstore="urn:BeanService" languageSpecificTy
pe="java:org.springframework.samples.jpetstore.domain.LineItem"/>
        <beanMapping qname="jpetstore:Item" xmlns:jpetstore="urn:BeanService" 
languageSpecificType="
java:org.springframework.samples.jpetstore.domain.Item"/>
        <beanMapping qname="jpetstore:Product" 
xmlns:jpetstore="urn:BeanService" languageSpecificTyp
e="java:org.springframework.samples.jpetstore.domain.Product"/>
 </service>


Now the problem I have is with the beanMappings.  My problem is the attribute
xmlns:jpetstore="urn:BeanService" and I kept wondering what the 
"urn:BeanService" was referring to, until I realized that is from one of the 
examples in the Axis distribution.

I think it would be much clearer if the beanMappings looked like:

<beanMapping qname="jpetstore:LineItem" xmlns:jpetstore="urn:JPetStore" .../>

I think that would make it easier for people coming into it (like me) to 
realize that the "urn:JPetStore" was just a local constant, instead of some
kind of deep magic - "urn:BeanService" is needlessly confusing.

I can make the changes myself and send in a patch if people are interested, 
but I figured that it's such a small change a comitter might find it easier 
to do themselves...

H

RE: [Springframework-developer] RE: [Springframework-user] chain ViewResolvers?

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

> Just catching up on the discussion (the problem of living so far away =
is
> that my day is your night :).
Hmmm, must have pressed the wrong button, accidentally moving the =
discussion
to the dev list...

> I'm curious why you think a ChainedViewResolver would be inconsistent.
> I view it as a new feature, not as breaking a pattern.  It certainly
> seems the most simple (maintains 1 viewresolver for the servlet, =
allows
> for explicit ordering by definition of the chain, doesn't change any
> semantics on return variables, etc).  Also, we can always add
> ChainedHandlerMapping.
Hmmm, just an opinion I guess. Defining a chain in a ChainedViewResolver =
or
ChainedHandlerMapping doesn't have any real value over the definition of
such HandlerMappings and ViewResolvers directly, Ordering is already
possible, etcetera. I think all of us aren't really fond of providing =
stuff
that doesn't have any added value.

The main reason why J=FCrgen proposed the ChainedViewResolver was =
basically to
maintain backward-compatibility, but that's been fixed now. You can =
tweak
the DispatcherServlet with a property enabling or disabling multiple
viewresolvers.

I saw you figured out the ordering already?

Alef

Re: [Springframework-developer] Comment fix for 'image-servlet.xml'

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

Thanks for spotting this - just fixed!
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Janek Bogucki
Gesendet: Di 04.05.2004 20:46
An: spr...@li...
Betreff: [Springframework-developer] Comment fix for 'image-servlet.xml'



From the imagedb sample from Spring Framework 1.0.1 there is a copy and
paste comment error in image-servlet.xml. The second comment needs to
refer to FreeMarker instead of Velocity.

        <!-- Configurer that sets up a VelocityEngine for Velocity views
-->
        <bean id=3D"velocityConfigurer"
class=3D"org.springframework.web.servlet.view.velocity.VelocityConfigurer=
">
                <property
name=3D"resourceLoaderPath"><value>WEB-INF/views/</value></property>
        </bean>

        <!-- Configurer that sets up a VelocityEngine for Velocity views
-->
        <bean id=3D"freemarkerConfigurer"
class=3D"org.springframework.web.servlet.view.freemarker.FreeMarkerConfig=
urer">
                <property
name=3D"templateLoaderPath"><value>WEB-INF/views/</value></property>
        </bean>

-Janek


-------------------------------------------------------
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] chain ViewResolvers?

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

Already committed - the new DispatcherServlet bean property is called =
"detectAllViewResolvers", default is true. If you're doing obscure =
things with ViewResolvers, simply turn "detectAllViewResolvers" off ;-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Alef Arendsen
Gesendet: Di 04.05.2004 18:46
An: spr...@li...
Betreff: RE: [Springframework-developer] chain ViewResolvers?



> I'm a bit torn between seeing the value of this feature and the issue =
with
> now treating all ViewResolver beans in the context as relevant for the
> DispatcherServlet.

Same here :(

> An option to easily allow backward compatibility would be a
> DispatcherServlet setting "allowMultipleViewResolvers", falling back =
to a
> single "viewResolver" bean if turned off. Question is: Should the =
default
> be "true" or "false"? I guess "true" would be fine, as long as we =
document
> that in the release notes. In case of obscure ViewResolver usage, =
simply
> specify "false" there.

I like this (also the default "true" value, as long as we mention it in =
the
rel.notes like you're saying)! It should however be removed again in 1.1
IMHO, no workarounds please that give users the ability to abuse Spring =
in
obscure manners ;-). Maybe include a task in JIRA or something just so =
we
won't forget?

> Regarding ViewResolver interface semantics: They actually were unclear
> before; the javadocs didn't exactly state when to throw an exception. =
I
> don't think that defining specific handling for null would cause
> compatibility headaches. I rather consider it an improvement to =
actually
> specify the expected behavior here.

You're right. It'll be mentioned in the changelog and maybe we could put
things in the release notes alongside the entry about the
allowMultipleViewREsolvers property...

> I completely agree that it would be much nicer to have multiple
> ViewResolver bean definitions rather than a separate =
ChainedViewResolver
> that in turn delegates to multiple ViewResolvers... I guess an =
explicit
> "allowMultipleViewResolvers" setting is a much better solution than a
> ChainedViewResolver.
Ok, the allowMultipleViewResolvers property it is then!

-aa

>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Alef Arendsen
> Sent: Tuesday, May 04, 2004 4:10 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] RE: [Springframework-user]
> chain ViewResolvers?
>
>
> > This is a major issue that I didn't consider - argh, my
> > over-eagerness ;-(
> No problem, without your eagerness, we wouldn't have come this far
> probably
> ;-).
>
> > ad 1) A ViewResolver implementation can implement Ordered. <snip>
> > ad 2) Well, there actually is a difference <snip>
> Ok, perfect.
>
> > Of course, the change would need to be documented. It's also =
something
> > that we could potentially delay till 1.1, if we consider the change =
too
> > much for a point release. (Although our point releases are actually
> > Hibernate/Tomcat-style point releases that introduce minor new
> > functionality and internal reworkings, rather than plain bugfix
> releases.)
> It's not a question of whether or not we want to add functionality and
> rework stuff IMO. One thing we have to consider at all times is that =
we
> have
> existing users and we don't know what they're using and how they're =
using
> it.
>
> > That said, we could also stick to a single "viewResolver" bean and =
offer
> a
> > "ChainedViewResolver" adapter that takes a List of further =
ViewResolvers
> > that it delegates to.
> Hmmm, the ChainedViewResolver would be inconsistent with the =
possibility
> of
> having multiple UrlHandlerMappings, which are NOT contained by a
> ChainedHandlerMapping or something like that... Once you get used to =
the
> way
> beans are defined in the WebApplicationContext it's really intuitive, =
so
> we
> shouldn't go and introduce concepts like this IMO.
>
> Also, I don't like workarounds or inconsistencies to be able to =
include
> something that might otherwise result in a non-backward-compability... =
So
> AFAIC the ChainedViewResolver is a no-go... This would mean we can't =
add
> the
> multiple viewresolvers... But I don't like that either!
>
> Provided that we put a big warning on the website mentioning this =
issue,
> I'm
> ok with the stuff that's in the CVS now (multiple resolvers, all at =
the
> root
> of the WebAppCtx).
>
> Alef
>
> p.s. sorry to be picky about this, but I already got a couple of
> compliments
> from people about release management being pretty good, I want to keep =
it
> that way...
>
> >
> > Juergen
> >
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]On =
Behalf
> > Of Alef Arendsen
> > Sent: Tuesday, May 04, 2004 12:16 PM
> > To: spr...@li...
> > Subject: [Springframework-developer] RE: [Springframework-user] =
chain
> > ViewResolvers?
> >
> >
> > Although I think this is a very useful addition, this should be
> documented
> > as a somewhat non-backward-compatible change, shouldn't it.
> >
> > A co-worker of mine recently sublcassed one of the viewresolvers and
> > implemented the controller interface. He returned
> >
> >   new ModelAndView(super.resolveView("whateverString"));
> >
> > Although the approach may seem odd, it worked quite well. It won't
> anymore
> > with 1.0.2. Besides the controller / viewrsesolver now being picked =
up
> as
> > a
> > viewresolver as well, the changed signature (return value) also =
affects
> it
> > (null ModelAndViews are not supported).
> >
> > Two other questions:
> >
> > 1) Ordering is determined using the normal procedures with
> > OrderComparator/Ordered? So ViewResolver now extends Ordered?
> >
> > 2) The behavior or the resolveView() method is not really clear =
anymore.
> > ViewResolver themselves are supposed to decide what they are =
returning,
> > either a View object that might have a non-existent underlying =
resource,
> > or
> > null, also indicating a non-existent resource. Although probably not
> > feasible, it would be nice the get the behavior of all the =
viewresolvers
> > in
> > line...
> >
> > Comments?
> >
> > I'll update the reference documentation as soon as things are =
cleared
> > out...
> >
> > Alef
> >
> >
> >
> > > -----Original Message-----
> > > From: spr...@li...
> > > [mailto:spr...@li...] On =
Behalf Of
> > > j=FCrgen h=F6ller [werk3AT]
> > > Sent: Tuesday, May 04, 2004 10:59 AM
> > > To: spr...@li...
> > > Subject: Re: [Springframework-user] chain ViewResolvers?
> > >
> > > This turned out so straightforward to do that I've just finished =
it -
> > > already committed to CVS :-)
> > >
> > > Juergen
> > >
> > >
> > > ________________________________
> > >
> > > Von: spr...@li... im Auftrag =
von
> > > j=FCrgen h=F6ller [werk3AT]
> > > Gesendet: Di 04.05.2004 08:01
> > > An: spr...@li...
> > > Betreff: Re: [Springframework-user] chain ViewResolvers?
> > >
> > >
> > >
> > > I see the point in having multiple ViewResolvers, so I'm inclined =
to
> > > change this for 1.0.2. In terms of DispatcherServlet bean =
definitions,
> > > this would mean checking for ViewResolver implementations rather =
than
> a
> > > bean with name "viewResolver", but that would be perfectly =
backward-
> > > compatible.
> > >
> > > The only semantic change that's necessary is the return value of
> > > ViewResolver's resolveViewName method: It should return null if =
not
> > found,
> > > just throwing an exception when there was a problem creating an =
actual
> > > view.  The current implementations either throw
> > > NoSuchBeanDefinitionException if not found (like XmlViewResolver), =
or
> > > always return a View object even if there's no underlying resource
> (like
> > > InternalResourceViewResolver).
> > >
> > > So you can't use InternalResourceViewResolver as your first
> > ViewResolver,
> > > as it will always return a View object - by its very nature. On =
the
> > other
> > > hand, InternalResourceViewResolver will be a typical fallback =
resolver
> > > anyway, with an XmlViewResolver or ResourceBundleViewResolver put =
in
> > > front.
> > >
> > > So what we could do is to refine the "resolveViewName" semantics =
to
> > allow
> > > for a null return value if not found, if the ViewResolver wants to
> > support
> > > resolver chaining. As this is not a requirement, backward
> compatibility
> > > won't be broken. We could then change XmlViewResolver and
> > > ResourceBundleViewResolver to return null if no bean with the view
> name
> > > found. Of course, DispatcherServlet will have to throw a "view not
> > > resolvable" exception if all ViewResolvers returned null.
> > >
> > > What do you think? As this is easy enough to implement, I might go
> ahead
> > > this evening if we agree on the change.
> > >
> > > Juergen
> > >
> > >
> > > ________________________________
> > >
> > > Von: spr...@li... im Auftrag =
von
> > Seth
> > > Ladd
> > > Gesendet: Di 04.05.2004 03:50
> > > An: spr...@li...
> > > Betreff: [Springframework-user] chain ViewResolvers?
> > >
> > >
> > >
> > > Hello,
> > >
> > > I saw an email here or on the forums asking if there was a reason =
for
> a
> > > single ViewResolver.  I, too, would like to be able to define =
multiple
> > > ViewResolvers and chain them together.  Most of the time, I would =
use
> > > the simple InternalResourceViewResolver.  For some views, though, =
I
> need
> > > more freeform creation and would like XmlViewResolver.  Being able =
to
> > > chain these together would give me the best of both worlds.  Less
> > > configuration is always a good thing.
> > >
> > > Thanks very much!
> > > Seth
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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-user mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-user
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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-user mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-user
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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-user mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-user
> >
> >
> >
> > -------------------------------------------------------
> > 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
>
>
>
> -------------------------------------------------------
> 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



-------------------------------------------------------
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] Comment fix for 'image-servlet.xml'

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

Thanks Janek, I'll change that.

Dmitriy.



Janek Bogucki wrote:

> From the imagedb sample from Spring Framework 1.0.1 there is a copy and
> paste comment error in image-servlet.xml. The second comment needs to
> refer to FreeMarker instead of Velocity.
> 
>         <!-- Configurer that sets up a VelocityEngine for Velocity views
> -->
>         <bean id="velocityConfigurer"
> class="org.springframework.web.servlet.view.velocity.VelocityConfigurer">
>                 <property
> name="resourceLoaderPath"><value>WEB-INF/views/</value></property>
>         </bean>
> 
>         <!-- Configurer that sets up a VelocityEngine for Velocity views
> -->
>         <bean id="freemarkerConfigurer"
> class="org.springframework.web.servlet.view.freemarker.FreeMarkerConfigurer">
>                 <property
> name="templateLoaderPath"><value>WEB-INF/views/</value></property>
>         </bean>
> 
> -Janek
> 
> 
> -------------------------------------------------------
> 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] Comment fix for 'image-servlet.xml'

[Janek B. <ya...@st...>]

From the imagedb sample from Spring Framework 1.0.1 there is a copy and
paste comment error in image-servlet.xml. The second comment needs to
refer to FreeMarker instead of Velocity.

        <!-- Configurer that sets up a VelocityEngine for Velocity views
-->
        <bean id="velocityConfigurer"
class="org.springframework.web.servlet.view.velocity.VelocityConfigurer">
                <property
name="resourceLoaderPath"><value>WEB-INF/views/</value></property>
        </bean>

        <!-- Configurer that sets up a VelocityEngine for Velocity views
-->
        <bean id="freemarkerConfigurer"
class="org.springframework.web.servlet.view.freemarker.FreeMarkerConfigurer">
                <property
name="templateLoaderPath"><value>WEB-INF/views/</value></property>
        </bean>

-Janek

Re: [Springframework-developer] RE: [Springframework-user] chain ViewResolvers?

[Seth L. <se...@eh...>]

>>That said, we could also stick to a single "viewResolver" bean and offer a
>>"ChainedViewResolver" adapter that takes a List of further ViewResolvers
>>that it delegates to.
> 
> Hmmm, the ChainedViewResolver would be inconsistent with the possibility of
> having multiple UrlHandlerMappings, which are NOT contained by a
> ChainedHandlerMapping or something like that... Once you get used to the way
> beans are defined in the WebApplicationContext it's really intuitive, so we
> shouldn't go and introduce concepts like this IMO.
> 
> Also, I don't like workarounds or inconsistencies to be able to include
> something that might otherwise result in a non-backward-compability... So
> AFAIC the ChainedViewResolver is a no-go... This would mean we can't add the
> multiple viewresolvers... But I don't like that either!

Just catching up on the discussion (the problem of living so far away is 
that my day is your night :).

I'm curious why you think a ChainedViewResolver would be inconsistent. 
I view it as a new feature, not as breaking a pattern.  It certainly 
seems the most simple (maintains 1 viewresolver for the servlet, allows 
for explicit ordering by definition of the chain, doesn't change any 
semantics on return variables, etc).  Also, we can always add 
ChainedHandlerMapping.

I'm not arguing, and I'm very pleased to see multiple viewresolvers now 
able to be specified (although still curious as to how to order, but 
will check that out shortly).  Just wondering what the thought process 
is from those who know Spring better than I. :)

Thanks!
Seth

RE: [Springframework-developer] chain ViewResolvers?

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

> I'm a bit torn between seeing the value of this feature and the issue =
with
> now treating all ViewResolver beans in the context as relevant for the
> DispatcherServlet.=20

Same here :(

> An option to easily allow backward compatibility would be a
> DispatcherServlet setting "allowMultipleViewResolvers", falling back =
to a
> single "viewResolver" bean if turned off. Question is: Should the =
default
> be "true" or "false"? I guess "true" would be fine, as long as we =
document
> that in the release notes. In case of obscure ViewResolver usage, =
simply
> specify "false" there.

I like this (also the default "true" value, as long as we mention it in =
the
rel.notes like you're saying)! It should however be removed again in 1.1
IMHO, no workarounds please that give users the ability to abuse Spring =
in
obscure manners ;-). Maybe include a task in JIRA or something just so =
we
won't forget?

> Regarding ViewResolver interface semantics: They actually were unclear
> before; the javadocs didn't exactly state when to throw an exception. =
I
> don't think that defining specific handling for null would cause
> compatibility headaches. I rather consider it an improvement to =
actually
> specify the expected behavior here.

You're right. It'll be mentioned in the changelog and maybe we could put
things in the release notes alongside the entry about the
allowMultipleViewREsolvers property...

> I completely agree that it would be much nicer to have multiple
> ViewResolver bean definitions rather than a separate =
ChainedViewResolver
> that in turn delegates to multiple ViewResolvers... I guess an =
explicit
> "allowMultipleViewResolvers" setting is a much better solution than a
> ChainedViewResolver.
Ok, the allowMultipleViewResolvers property it is then!

-aa

>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Alef Arendsen
> Sent: Tuesday, May 04, 2004 4:10 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] RE: [Springframework-user]
> chain ViewResolvers?
>=20
>=20
> > This is a major issue that I didn't consider - argh, my
> > over-eagerness ;-(
> No problem, without your eagerness, we wouldn't have come this far
> probably
> ;-).
>=20
> > ad 1) A ViewResolver implementation can implement Ordered. <snip>
> > ad 2) Well, there actually is a difference <snip>
> Ok, perfect.
>=20
> > Of course, the change would need to be documented. It's also =
something
> > that we could potentially delay till 1.1, if we consider the change =
too
> > much for a point release. (Although our point releases are actually
> > Hibernate/Tomcat-style point releases that introduce minor new
> > functionality and internal reworkings, rather than plain bugfix
> releases.)
> It's not a question of whether or not we want to add functionality and
> rework stuff IMO. One thing we have to consider at all times is that =
we
> have
> existing users and we don't know what they're using and how they're =
using
> it.
>=20
> > That said, we could also stick to a single "viewResolver" bean and =
offer
> a
> > "ChainedViewResolver" adapter that takes a List of further =
ViewResolvers
> > that it delegates to.
> Hmmm, the ChainedViewResolver would be inconsistent with the =
possibility
> of
> having multiple UrlHandlerMappings, which are NOT contained by a
> ChainedHandlerMapping or something like that... Once you get used to =
the
> way
> beans are defined in the WebApplicationContext it's really intuitive, =
so
> we
> shouldn't go and introduce concepts like this IMO.
>=20
> Also, I don't like workarounds or inconsistencies to be able to =
include
> something that might otherwise result in a non-backward-compability... =
So
> AFAIC the ChainedViewResolver is a no-go... This would mean we can't =
add
> the
> multiple viewresolvers... But I don't like that either!
>=20
> Provided that we put a big warning on the website mentioning this =
issue,
> I'm
> ok with the stuff that's in the CVS now (multiple resolvers, all at =
the
> root
> of the WebAppCtx).
>=20
> Alef
>=20
> p.s. sorry to be picky about this, but I already got a couple of
> compliments
> from people about release management being pretty good, I want to keep =
it
> that way...
>=20
> >
> > Juergen
> >
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]On =
Behalf
> > Of Alef Arendsen
> > Sent: Tuesday, May 04, 2004 12:16 PM
> > To: spr...@li...
> > Subject: [Springframework-developer] RE: [Springframework-user] =
chain
> > ViewResolvers?
> >
> >
> > Although I think this is a very useful addition, this should be
> documented
> > as a somewhat non-backward-compatible change, shouldn't it.
> >
> > A co-worker of mine recently sublcassed one of the viewresolvers and
> > implemented the controller interface. He returned
> >
> >   new ModelAndView(super.resolveView("whateverString"));
> >
> > Although the approach may seem odd, it worked quite well. It won't
> anymore
> > with 1.0.2. Besides the controller / viewrsesolver now being picked =
up
> as
> > a
> > viewresolver as well, the changed signature (return value) also =
affects
> it
> > (null ModelAndViews are not supported).
> >
> > Two other questions:
> >
> > 1) Ordering is determined using the normal procedures with
> > OrderComparator/Ordered? So ViewResolver now extends Ordered?
> >
> > 2) The behavior or the resolveView() method is not really clear =
anymore.
> > ViewResolver themselves are supposed to decide what they are =
returning,
> > either a View object that might have a non-existent underlying =
resource,
> > or
> > null, also indicating a non-existent resource. Although probably not
> > feasible, it would be nice the get the behavior of all the =
viewresolvers
> > in
> > line...
> >
> > Comments?
> >
> > I'll update the reference documentation as soon as things are =
cleared
> > out...
> >
> > Alef
> >
> >
> >
> > > -----Original Message-----
> > > From: spr...@li...
> > > [mailto:spr...@li...] On =
Behalf Of
> > > j=FCrgen h=F6ller [werk3AT]
> > > Sent: Tuesday, May 04, 2004 10:59 AM
> > > To: spr...@li...
> > > Subject: Re: [Springframework-user] chain ViewResolvers?
> > >
> > > This turned out so straightforward to do that I've just finished =
it -
> > > already committed to CVS :-)
> > >
> > > Juergen
> > >
> > >
> > > ________________________________
> > >
> > > Von: spr...@li... im Auftrag =
von
> > > j=FCrgen h=F6ller [werk3AT]
> > > Gesendet: Di 04.05.2004 08:01
> > > An: spr...@li...
> > > Betreff: Re: [Springframework-user] chain ViewResolvers?
> > >
> > >
> > >
> > > I see the point in having multiple ViewResolvers, so I'm inclined =
to
> > > change this for 1.0.2. In terms of DispatcherServlet bean =
definitions,
> > > this would mean checking for ViewResolver implementations rather =
than
> a
> > > bean with name "viewResolver", but that would be perfectly =
backward-
> > > compatible.
> > >
> > > The only semantic change that's necessary is the return value of
> > > ViewResolver's resolveViewName method: It should return null if =
not
> > found,
> > > just throwing an exception when there was a problem creating an =
actual
> > > view.  The current implementations either throw
> > > NoSuchBeanDefinitionException if not found (like XmlViewResolver), =
or
> > > always return a View object even if there's no underlying resource
> (like
> > > InternalResourceViewResolver).
> > >
> > > So you can't use InternalResourceViewResolver as your first
> > ViewResolver,
> > > as it will always return a View object - by its very nature. On =
the
> > other
> > > hand, InternalResourceViewResolver will be a typical fallback =
resolver
> > > anyway, with an XmlViewResolver or ResourceBundleViewResolver put =
in
> > > front.
> > >
> > > So what we could do is to refine the "resolveViewName" semantics =
to
> > allow
> > > for a null return value if not found, if the ViewResolver wants to
> > support
> > > resolver chaining. As this is not a requirement, backward
> compatibility
> > > won't be broken. We could then change XmlViewResolver and
> > > ResourceBundleViewResolver to return null if no bean with the view
> name
> > > found. Of course, DispatcherServlet will have to throw a "view not
> > > resolvable" exception if all ViewResolvers returned null.
> > >
> > > What do you think? As this is easy enough to implement, I might go
> ahead
> > > this evening if we agree on the change.
> > >
> > > Juergen
> > >
> > >
> > > ________________________________
> > >
> > > Von: spr...@li... im Auftrag =
von
> > Seth
> > > Ladd
> > > Gesendet: Di 04.05.2004 03:50
> > > An: spr...@li...
> > > Betreff: [Springframework-user] chain ViewResolvers?
> > >
> > >
> > >
> > > Hello,
> > >
> > > I saw an email here or on the forums asking if there was a reason =
for
> a
> > > single ViewResolver.  I, too, would like to be able to define =
multiple
> > > ViewResolvers and chain them together.  Most of the time, I would =
use
> > > the simple InternalResourceViewResolver.  For some views, though, =
I
> need
> > > more freeform creation and would like XmlViewResolver.  Being able =
to
> > > chain these together would give me the best of both worlds.  Less
> > > configuration is always a good thing.
> > >
> > > Thanks very much!
> > > Seth
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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-user mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-user
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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-user mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-user
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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-user mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-user
> >
> >
> >
> > -------------------------------------------------------
> > 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
>=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=3Dick
> _______________________________________________
> 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] chain ViewResolvers?

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

I'm a bit torn between seeing the value of this feature and the issue =
with now treating all ViewResolver beans in the context as relevant for =
the DispatcherServlet. I do believe that 99.9% of all applications are =
not affected by this, but some rather obscure usages might. However, it =
should be easy to rewrite such obscure usages to not rely on separate =
ViewResolvers.

An option to easily allow backward compatibility would be a =
DispatcherServlet setting "allowMultipleViewResolvers", falling back to =
a single "viewResolver" bean if turned off. Question is: Should the =
default be "true" or "false"? I guess "true" would be fine, as long as =
we document that in the release notes. In case of obscure ViewResolver =
usage, simply specify "false" there.

Regarding ViewResolver interface semantics: They actually were unclear =
before; the javadocs didn't exactly state when to throw an exception. I =
don't think that defining specific handling for null would cause =
compatibility headaches. I rather consider it an improvement to actually =
specify the expected behavior here.

I completely agree that it would be much nicer to have multiple =
ViewResolver bean definitions rather than a separate ChainedViewResolver =
that in turn delegates to multiple ViewResolvers... I guess an explicit =
"allowMultipleViewResolvers" setting is a much better solution than a =
ChainedViewResolver.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Alef Arendsen
Sent: Tuesday, May 04, 2004 4:10 PM
To: spr...@li...
Subject: RE: [Springframework-developer] RE: [Springframework-user]
chain ViewResolvers?


> This is a major issue that I didn't consider - argh, my
> over-eagerness ;-(
No problem, without your eagerness, we wouldn't have come this far =
probably
;-).

> ad 1) A ViewResolver implementation can implement Ordered. <snip>
> ad 2) Well, there actually is a difference <snip>
Ok, perfect.

> Of course, the change would need to be documented. It's also something
> that we could potentially delay till 1.1, if we consider the change =
too
> much for a point release. (Although our point releases are actually
> Hibernate/Tomcat-style point releases that introduce minor new
> functionality and internal reworkings, rather than plain bugfix =
releases.)
It's not a question of whether or not we want to add functionality and
rework stuff IMO. One thing we have to consider at all times is that we =
have
existing users and we don't know what they're using and how they're =
using
it.

> That said, we could also stick to a single "viewResolver" bean and =
offer a
> "ChainedViewResolver" adapter that takes a List of further =
ViewResolvers
> that it delegates to.
Hmmm, the ChainedViewResolver would be inconsistent with the possibility =
of
having multiple UrlHandlerMappings, which are NOT contained by a
ChainedHandlerMapping or something like that... Once you get used to the =
way
beans are defined in the WebApplicationContext it's really intuitive, so =
we
shouldn't go and introduce concepts like this IMO.

Also, I don't like workarounds or inconsistencies to be able to include
something that might otherwise result in a non-backward-compability... =
So
AFAIC the ChainedViewResolver is a no-go... This would mean we can't add =
the
multiple viewresolvers... But I don't like that either!

Provided that we put a big warning on the website mentioning this issue, =
I'm
ok with the stuff that's in the CVS now (multiple resolvers, all at the =
root
of the WebAppCtx).=20

Alef

p.s. sorry to be picky about this, but I already got a couple of =
compliments
from people about release management being pretty good, I want to keep =
it
that way...

>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Alef Arendsen
> Sent: Tuesday, May 04, 2004 12:16 PM
> To: spr...@li...
> Subject: [Springframework-developer] RE: [Springframework-user] chain
> ViewResolvers?
>=20
>=20
> Although I think this is a very useful addition, this should be =
documented
> as a somewhat non-backward-compatible change, shouldn't it.
>=20
> A co-worker of mine recently sublcassed one of the viewresolvers and
> implemented the controller interface. He returned
>=20
>   new ModelAndView(super.resolveView("whateverString"));
>=20
> Although the approach may seem odd, it worked quite well. It won't =
anymore
> with 1.0.2. Besides the controller / viewrsesolver now being picked up =
as
> a
> viewresolver as well, the changed signature (return value) also =
affects it
> (null ModelAndViews are not supported).
>=20
> Two other questions:
>=20
> 1) Ordering is determined using the normal procedures with
> OrderComparator/Ordered? So ViewResolver now extends Ordered?
>=20
> 2) The behavior or the resolveView() method is not really clear =
anymore.
> ViewResolver themselves are supposed to decide what they are =
returning,
> either a View object that might have a non-existent underlying =
resource,
> or
> null, also indicating a non-existent resource. Although probably not
> feasible, it would be nice the get the behavior of all the =
viewresolvers
> in
> line...
>=20
> Comments?
>=20
> I'll update the reference documentation as soon as things are cleared
> out...
>=20
> Alef
>=20
>=20
>=20
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On Behalf =
Of
> > j=FCrgen h=F6ller [werk3AT]
> > Sent: Tuesday, May 04, 2004 10:59 AM
> > To: spr...@li...
> > Subject: Re: [Springframework-user] chain ViewResolvers?
> >
> > This turned out so straightforward to do that I've just finished it =
-
> > already committed to CVS :-)
> >
> > Juergen
> >
> >
> > ________________________________
> >
> > Von: spr...@li... im Auftrag von
> > j=FCrgen h=F6ller [werk3AT]
> > Gesendet: Di 04.05.2004 08:01
> > An: spr...@li...
> > Betreff: Re: [Springframework-user] chain ViewResolvers?
> >
> >
> >
> > I see the point in having multiple ViewResolvers, so I'm inclined to
> > change this for 1.0.2. In terms of DispatcherServlet bean =
definitions,
> > this would mean checking for ViewResolver implementations rather =
than a
> > bean with name "viewResolver", but that would be perfectly backward-
> > compatible.
> >
> > The only semantic change that's necessary is the return value of
> > ViewResolver's resolveViewName method: It should return null if not
> found,
> > just throwing an exception when there was a problem creating an =
actual
> > view.  The current implementations either throw
> > NoSuchBeanDefinitionException if not found (like XmlViewResolver), =
or
> > always return a View object even if there's no underlying resource =
(like
> > InternalResourceViewResolver).
> >
> > So you can't use InternalResourceViewResolver as your first
> ViewResolver,
> > as it will always return a View object - by its very nature. On the
> other
> > hand, InternalResourceViewResolver will be a typical fallback =
resolver
> > anyway, with an XmlViewResolver or ResourceBundleViewResolver put in
> > front.
> >
> > So what we could do is to refine the "resolveViewName" semantics to
> allow
> > for a null return value if not found, if the ViewResolver wants to
> support
> > resolver chaining. As this is not a requirement, backward =
compatibility
> > won't be broken. We could then change XmlViewResolver and
> > ResourceBundleViewResolver to return null if no bean with the view =
name
> > found. Of course, DispatcherServlet will have to throw a "view not
> > resolvable" exception if all ViewResolvers returned null.
> >
> > What do you think? As this is easy enough to implement, I might go =
ahead
> > this evening if we agree on the change.
> >
> > Juergen
> >
> >
> > ________________________________
> >
> > Von: spr...@li... im Auftrag von
> Seth
> > Ladd
> > Gesendet: Di 04.05.2004 03:50
> > An: spr...@li...
> > Betreff: [Springframework-user] chain ViewResolvers?
> >
> >
> >
> > Hello,
> >
> > I saw an email here or on the forums asking if there was a reason =
for a
> > single ViewResolver.  I, too, would like to be able to define =
multiple
> > ViewResolvers and chain them together.  Most of the time, I would =
use
> > the simple InternalResourceViewResolver.  For some views, though, I =
need
> > more freeform creation and would like XmlViewResolver.  Being able =
to
> > chain these together would give me the best of both worlds.  Less
> > configuration is always a good thing.
> >
> > Thanks very much!
> > Seth
> >
> >
> >
> > -------------------------------------------------------
> > 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-user mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-user
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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-user mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-user
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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-user mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-user
>=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=3Dick
> _______________________________________________
> 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



-------------------------------------------------------
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_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

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

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

Well,

for instance SQLErrorCodesFactory is a singleton(GoF, not Spring) which caches SQLErrorCodes internally in the Map with strong references. Again, I don't know if trying 
to use WeakHashMap there would do the trick...

Dmitriy

Tim Kettering wrote:

> 
> I looked at it some more this morning, and basically what I did was  
> start up tomcat w/ the webapp in the profiler, then after it was done  
> starting up I used tomcat's manager to stop the context.  This should  
> destroy all resources related to the context.   Here is a list of  
> spring related stuff that still were in memory after the context was  
> closed.  Other stuff was cleaned up just fine.
> 
> org.springframework.beans.CachedIntrospectionResults
> org.springframework.jdbc.support.SQLCodes
> org.springframework.core.Constants
> org.springframework.aop.framework.AdvisedSupport$1
> org.springframework.aop.framework.adapter.BeforeAdviceAdapter
> org.springframework.aop.framework.adapter.AfterReturningAdviceAdapter
> org.springframework.jdbc.support.SQLErrorCodesFactory
> org.springframework.transaction.support.TransactionSynchronizationManage 
> r$1
> org.springframework.transaction.interceptor.RollbackRuleAttribute
> org.springframework.aop.framework.adapter.ThrosAdviceAdapter
> org.springframework.aop.Pointcut$1
> org.springframework.aop.framework.adapter.GlobalAdvisorAdapterRegistry
> 
> On May 3, 2004, at 3:28 PM, Dmitriy Kopylenko wrote:
> 
>> 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.<in 
>>> it >
>>> 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
>>
>>
>>
>>
>> -------------------------------------------------------
>> 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] Cleanup of context resources on webapp reload

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

I looked at it some more this morning, and basically what I did was  
start up tomcat w/ the webapp in the profiler, then after it was done  
starting up I used tomcat's manager to stop the context.  This should  
destroy all resources related to the context.   Here is a list of  
spring related stuff that still were in memory after the context was  
closed.  Other stuff was cleaned up just fine.

org.springframework.beans.CachedIntrospectionResults
org.springframework.jdbc.support.SQLCodes
org.springframework.core.Constants
org.springframework.aop.framework.AdvisedSupport$1
org.springframework.aop.framework.adapter.BeforeAdviceAdapter
org.springframework.aop.framework.adapter.AfterReturningAdviceAdapter
org.springframework.jdbc.support.SQLErrorCodesFactory
org.springframework.transaction.support.TransactionSynchronizationManage 
r$1
org.springframework.transaction.interceptor.RollbackRuleAttribute
org.springframework.aop.framework.adapter.ThrosAdviceAdapter
org.springframework.aop.Pointcut$1
org.springframework.aop.framework.adapter.GlobalAdvisorAdapterRegistry

On May 3, 2004, at 3:28 PM, Dmitriy Kopylenko wrote:

> 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.<in 
>> it >
>> 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
>
>
>
> -------------------------------------------------------
> 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] Cleanup of context resources on webapp reload

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

I believe that the minimum JDK supported by Spring is 1.3 There are some Spring deployments (WebSphere 4 and 5 running 1.3 for instance)...

Dmitriy.

Les A. Hazlewood wrote:

> Quoting Dmitriy Kopylenko <dko...@ru...>:
> 
> 
>>I'm just wondering, would the use of WeakHashMap in
>>CachedIntrospectionResults help?
> 
> 
> I'm curious about CachedIntrospectionResults for another reason...
> 
> What is the minimum JDK supported by Spring?
> 
> If its JDK 1.4, I would argue that CachedIntrospectionResults is an unnecessary
> class (and infact incurs additional runtime memory overhead).
> 
> JDK 1.4 already caches its bean introspection results, including method and
> property descriptors, and it does so using WeakHashMaps.  So when you do a
> lookup for a bean, it returns the previously cached info (otherwise it does the
> introspection and then caches it).  CachedIntrospectionResults more or less
> duplicates what the 1.4 java.beans.Introspector already does.
> 
> If the minimum JDK supported by Spring is < 1.4, I can understand keeping the
> class, otherwise, wouldn't it be better to deprecate it?
> 
> If so, it would be an easy fix, since CachedIntrospectionResults is only used in
> o.s.beans.BeanWrapperImpl in two places to retrieve PropertyDescriptors.
> 
> Any thoughts?
> 
> Les
> 
> 
> -------------------------------------------------------
> 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] Cleanup of context resources on webapp reload

[Les A. H. <le...@ha...>]

Quoting Dmitriy Kopylenko <dko...@ru...>:

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

I'm curious about CachedIntrospectionResults for another reason...

What is the minimum JDK supported by Spring?

If its JDK 1.4, I would argue that CachedIntrospectionResults is an unnecessary
class (and infact incurs additional runtime memory overhead).

JDK 1.4 already caches its bean introspection results, including method and
property descriptors, and it does so using WeakHashMaps.  So when you do a
lookup for a bean, it returns the previously cached info (otherwise it does the
introspection and then caches it).  CachedIntrospectionResults more or less
duplicates what the 1.4 java.beans.Introspector already does.

If the minimum JDK supported by Spring is < 1.4, I can understand keeping the
class, otherwise, wouldn't it be better to deprecate it?

If so, it would be an easy fix, since CachedIntrospectionResults is only used in
o.s.beans.BeanWrapperImpl in two places to retrieve PropertyDescriptors.

Any thoughts?

Les

RE: [Springframework-developer] RE: [Springframework-user] chain ViewResolvers?

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

> This is a major issue that I didn't consider - argh, my
> over-eagerness ;-(
No problem, without your eagerness, we wouldn't have come this far =
probably
;-).

> ad 1) A ViewResolver implementation can implement Ordered. <snip>
> ad 2) Well, there actually is a difference <snip>
Ok, perfect.

> Of course, the change would need to be documented. It's also something
> that we could potentially delay till 1.1, if we consider the change =
too
> much for a point release. (Although our point releases are actually
> Hibernate/Tomcat-style point releases that introduce minor new
> functionality and internal reworkings, rather than plain bugfix =
releases.)
It's not a question of whether or not we want to add functionality and
rework stuff IMO. One thing we have to consider at all times is that we =
have
existing users and we don't know what they're using and how they're =
using
it.

> That said, we could also stick to a single "viewResolver" bean and =
offer a
> "ChainedViewResolver" adapter that takes a List of further =
ViewResolvers
> that it delegates to.
Hmmm, the ChainedViewResolver would be inconsistent with the possibility =
of
having multiple UrlHandlerMappings, which are NOT contained by a
ChainedHandlerMapping or something like that... Once you get used to the =
way
beans are defined in the WebApplicationContext it's really intuitive, so =
we
shouldn't go and introduce concepts like this IMO.

Also, I don't like workarounds or inconsistencies to be able to include
something that might otherwise result in a non-backward-compability... =
So
AFAIC the ChainedViewResolver is a no-go... This would mean we can't add =
the
multiple viewresolvers... But I don't like that either!

Provided that we put a big warning on the website mentioning this issue, =
I'm
ok with the stuff that's in the CVS now (multiple resolvers, all at the =
root
of the WebAppCtx).=20

Alef

p.s. sorry to be picky about this, but I already got a couple of =
compliments
from people about release management being pretty good, I want to keep =
it
that way...

>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Alef Arendsen
> Sent: Tuesday, May 04, 2004 12:16 PM
> To: spr...@li...
> Subject: [Springframework-developer] RE: [Springframework-user] chain
> ViewResolvers?
>=20
>=20
> Although I think this is a very useful addition, this should be =
documented
> as a somewhat non-backward-compatible change, shouldn't it.
>=20
> A co-worker of mine recently sublcassed one of the viewresolvers and
> implemented the controller interface. He returned
>=20
>   new ModelAndView(super.resolveView("whateverString"));
>=20
> Although the approach may seem odd, it worked quite well. It won't =
anymore
> with 1.0.2. Besides the controller / viewrsesolver now being picked up =
as
> a
> viewresolver as well, the changed signature (return value) also =
affects it
> (null ModelAndViews are not supported).
>=20
> Two other questions:
>=20
> 1) Ordering is determined using the normal procedures with
> OrderComparator/Ordered? So ViewResolver now extends Ordered?
>=20
> 2) The behavior or the resolveView() method is not really clear =
anymore.
> ViewResolver themselves are supposed to decide what they are =
returning,
> either a View object that might have a non-existent underlying =
resource,
> or
> null, also indicating a non-existent resource. Although probably not
> feasible, it would be nice the get the behavior of all the =
viewresolvers
> in
> line...
>=20
> Comments?
>=20
> I'll update the reference documentation as soon as things are cleared
> out...
>=20
> Alef
>=20
>=20
>=20
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On Behalf =
Of
> > j=FCrgen h=F6ller [werk3AT]
> > Sent: Tuesday, May 04, 2004 10:59 AM
> > To: spr...@li...
> > Subject: Re: [Springframework-user] chain ViewResolvers?
> >
> > This turned out so straightforward to do that I've just finished it =
-
> > already committed to CVS :-)
> >
> > Juergen
> >
> >
> > ________________________________
> >
> > Von: spr...@li... im Auftrag von
> > j=FCrgen h=F6ller [werk3AT]
> > Gesendet: Di 04.05.2004 08:01
> > An: spr...@li...
> > Betreff: Re: [Springframework-user] chain ViewResolvers?
> >
> >
> >
> > I see the point in having multiple ViewResolvers, so I'm inclined to
> > change this for 1.0.2. In terms of DispatcherServlet bean =
definitions,
> > this would mean checking for ViewResolver implementations rather =
than a
> > bean with name "viewResolver", but that would be perfectly backward-
> > compatible.
> >
> > The only semantic change that's necessary is the return value of
> > ViewResolver's resolveViewName method: It should return null if not
> found,
> > just throwing an exception when there was a problem creating an =
actual
> > view.  The current implementations either throw
> > NoSuchBeanDefinitionException if not found (like XmlViewResolver), =
or
> > always return a View object even if there's no underlying resource =
(like
> > InternalResourceViewResolver).
> >
> > So you can't use InternalResourceViewResolver as your first
> ViewResolver,
> > as it will always return a View object - by its very nature. On the
> other
> > hand, InternalResourceViewResolver will be a typical fallback =
resolver
> > anyway, with an XmlViewResolver or ResourceBundleViewResolver put in
> > front.
> >
> > So what we could do is to refine the "resolveViewName" semantics to
> allow
> > for a null return value if not found, if the ViewResolver wants to
> support
> > resolver chaining. As this is not a requirement, backward =
compatibility
> > won't be broken. We could then change XmlViewResolver and
> > ResourceBundleViewResolver to return null if no bean with the view =
name
> > found. Of course, DispatcherServlet will have to throw a "view not
> > resolvable" exception if all ViewResolvers returned null.
> >
> > What do you think? As this is easy enough to implement, I might go =
ahead
> > this evening if we agree on the change.
> >
> > Juergen
> >
> >
> > ________________________________
> >
> > Von: spr...@li... im Auftrag von
> Seth
> > Ladd
> > Gesendet: Di 04.05.2004 03:50
> > An: spr...@li...
> > Betreff: [Springframework-user] chain ViewResolvers?
> >
> >
> >
> > Hello,
> >
> > I saw an email here or on the forums asking if there was a reason =
for a
> > single ViewResolver.  I, too, would like to be able to define =
multiple
> > ViewResolvers and chain them together.  Most of the time, I would =
use
> > the simple InternalResourceViewResolver.  For some views, though, I =
need
> > more freeform creation and would like XmlViewResolver.  Being able =
to
> > chain these together would give me the best of both worlds.  Less
> > configuration is always a good thing.
> >
> > Thanks very much!
> > Seth
> >
> >
> >
> > -------------------------------------------------------
> > 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-user mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-user
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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-user mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-user
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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-user mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-user
>=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=3Dick
> _______________________________________________
> 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] EasyMock 1.1

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

No problem. It's been a few months since I updated any libs, so when I 
wanted to do this one I didn't remember if we normally do or don't add 
the version on the name; I think I just went into a few of the lib dirs 
and managed to hit the ones with version numbers, so assumed it was an 
oversight for this jar.

jürgen höller [werk3AT] wrote:

>I've just updated easymock.jar itself to 1.1, removing easymock-1.1.jar. Particularly for such minor updates, we should stick to the original jar names as used by the distributions of the respective projects. At least, that's what we currently do with all other libs. I'm aware that there've already been discussions on adding versions to all jar names; I'm still not keen on this. For example, I have to adapt my IDEA class path every time a jar name changes... And the version history in CVS isn't obvious either.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: Mo 03.05.2004 02:26
>An: spr...@li...
>Betreff: [Springframework-developer] EasyMock 1.1
>
>
>
>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
>    *
>
>
>
>
>
>-------------------------------------------------------
>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_id149&alloc_id66&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...>]

I don't have the 1.0 spec handy here, but I'm pretty sure field-specific 
lazy loading is not part of the JDO spec. Kodo didn't have this feature 
when I worked with it back in late 2001/early 2002, but they've extended 
it a lot since then, so I wouldn't be that surprised if it supported it now.

It's a bit of a bummer not being able to do it, since with the LOBs, 
that omission means you are forced to either load them all in via a 
transaparent LOB to string/byte mechanism, or use a non-transparent 
approach such as using the LobHandler, which has the added disadvantage 
that you can't use it to pass around the data once you are detached from 
the db.


jürgen höller [werk3AT] wrote:

>Isn't field-specific lazy loading a required feature of JDO? What does Kodo JDO offer in that respect, for example? Can you lazily load LOB fields in a database-independent manner with Kodo?
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: Mo 03.05.2004 20:18
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Exposing LOB support to Jdbc Object layer
>
>
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>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.
>>
>>
>>    
>>
>I've been trying to convince Gavin for ages to make it possible to lazy
>load columns (not just collections), which would make stuff like
>ClobStringType a lot more useful. Right now if you have a table with a
>LOB column and use something like ClobStringType you pay the price and
>load it even if you don't need it.
>
>Oh well...
>  
>

Re: [Springframework-developer] RE: [Springframework-user] chain ViewResolvers?

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

Alef, you've got some valid points there.

resolveView's return value should not be too relevant: It would have =
thrown a NoSuchBeanDefinitionException before (in case of =
XmlViewResolver or ResourceBundleViewResolver); now DispatcherServlet =
will throw a corresponding ServletException if it gets a null value from =
all resolvers. This will also happen if ModelAndView contains neither a =
view name nor a View object, so I don't see misbehavior in that =
particular case.

An important point is that all ViewResolver implementations will now be =
considered ViewResolvers for the containing DispatcherServlet. This =
shouldn't affect 99.9% of all applications, as there's hardly any use =
case for further ViewResolvers in the context. The Controller that =
implements ViewResolver sure seems odd, but unfortunately such things =
are valid in current Spring. This is a major issue that I didn't =
consider - argh, my over-eagerness ;-(

ad 1) A ViewResolver implementation can implement Ordered. It's not =
required in the interface. (Neither is it for HandlerMappings etc).

ad 2) Well, there actually is a difference: resolveViewName is supposed =
to return null if there's no view *definition*. An exception should just =
get thrown if an existing view definition cannot be turned into a View =
object. UrlBasedViewResolvers do not work with view definitions but =
directly create a View object from the view name, therefore they will =
never return null.

Of course, the change would need to be documented. It's also something =
that we could potentially delay till 1.1, if we consider the change too =
much for a point release. (Although our point releases are actually =
Hibernate/Tomcat-style point releases that introduce minor new =
functionality and internal reworkings, rather than plain bugfix =
releases.)

That said, we could also stick to a single "viewResolver" bean and offer =
a "ChainedViewResolver" adapter that takes a List of further =
ViewResolvers that it delegates to. Unfortunately, the resolveViewName =
return value is still relevant: We should be able to discriminate =
between "no view definition found" (-> check further ViewResolvers) and =
"could not create View object" (-> throw immediately) here...

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Alef Arendsen
Sent: Tuesday, May 04, 2004 12:16 PM
To: spr...@li...
Subject: [Springframework-developer] RE: [Springframework-user] chain
ViewResolvers?


Although I think this is a very useful addition, this should be =
documented
as a somewhat non-backward-compatible change, shouldn't it.

A co-worker of mine recently sublcassed one of the viewresolvers and
implemented the controller interface. He returned=20

  new ModelAndView(super.resolveView("whateverString"));

Although the approach may seem odd, it worked quite well. It won't =
anymore
with 1.0.2. Besides the controller / viewrsesolver now being picked up =
as a
viewresolver as well, the changed signature (return value) also affects =
it
(null ModelAndViews are not supported).

Two other questions:=20

1) Ordering is determined using the normal procedures with
OrderComparator/Ordered? So ViewResolver now extends Ordered?
=20
2) The behavior or the resolveView() method is not really clear anymore.
ViewResolver themselves are supposed to decide what they are returning,
either a View object that might have a non-existent underlying resource, =
or
null, also indicating a non-existent resource. Although probably not
feasible, it would be nice the get the behavior of all the viewresolvers =
in
line...

Comments?

I'll update the reference documentation as soon as things are cleared =
out...

Alef



> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf Of
> j=FCrgen h=F6ller [werk3AT]
> Sent: Tuesday, May 04, 2004 10:59 AM
> To: spr...@li...
> Subject: Re: [Springframework-user] chain ViewResolvers?
>=20
> This turned out so straightforward to do that I've just finished it -
> already committed to CVS :-)
>=20
> Juergen
>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag von
> j=FCrgen h=F6ller [werk3AT]
> Gesendet: Di 04.05.2004 08:01
> An: spr...@li...
> Betreff: Re: [Springframework-user] chain ViewResolvers?
>=20
>=20
>=20
> I see the point in having multiple ViewResolvers, so I'm inclined to
> change this for 1.0.2. In terms of DispatcherServlet bean definitions,
> this would mean checking for ViewResolver implementations rather than =
a
> bean with name "viewResolver", but that would be perfectly backward-
> compatible.
>=20
> The only semantic change that's necessary is the return value of
> ViewResolver's resolveViewName method: It should return null if not =
found,
> just throwing an exception when there was a problem creating an actual
> view.  The current implementations either throw
> NoSuchBeanDefinitionException if not found (like XmlViewResolver), or
> always return a View object even if there's no underlying resource =
(like
> InternalResourceViewResolver).
>=20
> So you can't use InternalResourceViewResolver as your first =
ViewResolver,
> as it will always return a View object - by its very nature. On the =
other
> hand, InternalResourceViewResolver will be a typical fallback resolver
> anyway, with an XmlViewResolver or ResourceBundleViewResolver put in
> front.
>=20
> So what we could do is to refine the "resolveViewName" semantics to =
allow
> for a null return value if not found, if the ViewResolver wants to =
support
> resolver chaining. As this is not a requirement, backward =
compatibility
> won't be broken. We could then change XmlViewResolver and
> ResourceBundleViewResolver to return null if no bean with the view =
name
> found. Of course, DispatcherServlet will have to throw a "view not
> resolvable" exception if all ViewResolvers returned null.
>=20
> What do you think? As this is easy enough to implement, I might go =
ahead
> this evening if we agree on the change.
>=20
> Juergen
>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag von =
Seth
> Ladd
> Gesendet: Di 04.05.2004 03:50
> An: spr...@li...
> Betreff: [Springframework-user] chain ViewResolvers?
>=20
>=20
>=20
> Hello,
>=20
> I saw an email here or on the forums asking if there was a reason for =
a
> single ViewResolver.  I, too, would like to be able to define multiple
> ViewResolvers and chain them together.  Most of the time, I would use
> the simple InternalResourceViewResolver.  For some views, though, I =
need
> more freeform creation and would like XmlViewResolver.  Being able to
> chain these together would give me the best of both worlds.  Less
> configuration is always a good thing.
>=20
> Thanks very much!
> Seth
>=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-user mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-user
>=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=3Dick
> _______________________________________________
> Springframework-user mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-user
>=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=3Dick
> _______________________________________________
> Springframework-user mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-user



-------------------------------------------------------
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_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] RE: [Springframework-user] chain ViewResolvers?

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

Although I think this is a very useful addition, this should be =
documented
as a somewhat non-backward-compatible change, shouldn't it.

A co-worker of mine recently sublcassed one of the viewresolvers and
implemented the controller interface. He returned=20

  new ModelAndView(super.resolveView("whateverString"));

Although the approach may seem odd, it worked quite well. It won't =
anymore
with 1.0.2. Besides the controller / viewrsesolver now being picked up =
as a
viewresolver as well, the changed signature (return value) also affects =
it
(null ModelAndViews are not supported).

Two other questions:=20

1) Ordering is determined using the normal procedures with
OrderComparator/Ordered? So ViewResolver now extends Ordered?
=20
2) The behavior or the resolveView() method is not really clear anymore.
ViewResolver themselves are supposed to decide what they are returning,
either a View object that might have a non-existent underlying resource, =
or
null, also indicating a non-existent resource. Although probably not
feasible, it would be nice the get the behavior of all the viewresolvers =
in
line...

Comments?

I'll update the reference documentation as soon as things are cleared =
out...

Alef



> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf Of
> j=FCrgen h=F6ller [werk3AT]
> Sent: Tuesday, May 04, 2004 10:59 AM
> To: spr...@li...
> Subject: Re: [Springframework-user] chain ViewResolvers?
>=20
> This turned out so straightforward to do that I've just finished it -
> already committed to CVS :-)
>=20
> Juergen
>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag von
> j=FCrgen h=F6ller [werk3AT]
> Gesendet: Di 04.05.2004 08:01
> An: spr...@li...
> Betreff: Re: [Springframework-user] chain ViewResolvers?
>=20
>=20
>=20
> I see the point in having multiple ViewResolvers, so I'm inclined to
> change this for 1.0.2. In terms of DispatcherServlet bean definitions,
> this would mean checking for ViewResolver implementations rather than =
a
> bean with name "viewResolver", but that would be perfectly backward-
> compatible.
>=20
> The only semantic change that's necessary is the return value of
> ViewResolver's resolveViewName method: It should return null if not =
found,
> just throwing an exception when there was a problem creating an actual
> view.  The current implementations either throw
> NoSuchBeanDefinitionException if not found (like XmlViewResolver), or
> always return a View object even if there's no underlying resource =
(like
> InternalResourceViewResolver).
>=20
> So you can't use InternalResourceViewResolver as your first =
ViewResolver,
> as it will always return a View object - by its very nature. On the =
other
> hand, InternalResourceViewResolver will be a typical fallback resolver
> anyway, with an XmlViewResolver or ResourceBundleViewResolver put in
> front.
>=20
> So what we could do is to refine the "resolveViewName" semantics to =
allow
> for a null return value if not found, if the ViewResolver wants to =
support
> resolver chaining. As this is not a requirement, backward =
compatibility
> won't be broken. We could then change XmlViewResolver and
> ResourceBundleViewResolver to return null if no bean with the view =
name
> found. Of course, DispatcherServlet will have to throw a "view not
> resolvable" exception if all ViewResolvers returned null.
>=20
> What do you think? As this is easy enough to implement, I might go =
ahead
> this evening if we agree on the change.
>=20
> Juergen
>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag von =
Seth
> Ladd
> Gesendet: Di 04.05.2004 03:50
> An: spr...@li...
> Betreff: [Springframework-user] chain ViewResolvers?
>=20
>=20
>=20
> Hello,
>=20
> I saw an email here or on the forums asking if there was a reason for =
a
> single ViewResolver.  I, too, would like to be able to define multiple
> ViewResolvers and chain them together.  Most of the time, I would use
> the simple InternalResourceViewResolver.  For some views, though, I =
need
> more freeform creation and would like XmlViewResolver.  Being able to
> chain these together would give me the best of both worlds.  Less
> configuration is always a good thing.
>=20
> Thanks very much!
> Seth
>=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-user mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-user
>=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=3Dick
> _______________________________________________
> Springframework-user mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-user
>=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=3Dick
> _______________________________________________
> Springframework-user mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-user

Re: [Springframework-developer] EasyMock 1.1

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

I've just updated easymock.jar itself to 1.1, removing easymock-1.1.jar. =
Particularly for such minor updates, we should stick to the original jar =
names as used by the distributions of the respective projects. At least, =
that's what we currently do with all other libs. I'm aware that there've =
already been discussions on adding versions to all jar names; I'm still =
not keen on this. For example, I have to adapt my IDEA class path every =
time a jar name changes... And the version history in CVS isn't obvious =
either.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Mo 03.05.2004 02:26
An: spr...@li...
Betreff: [Springframework-developer] EasyMock 1.1



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
    *





-------------------------------------------------------
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] Exposing LOB support to Jdbc Object layer

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

Isn't field-specific lazy loading a required feature of JDO? What does =
Kodo JDO offer in that respect, for example? Can you lazily load LOB =
fields in a database-independent manner with Kodo?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Mo 03.05.2004 20:18
An: spr...@li...
Betreff: Re: [Springframework-developer] Exposing LOB support to Jdbc =
Object layer



j=FCrgen h=F6ller [werk3AT] wrote:

>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.
>=20
>
I've been trying to convince Gavin for ages to make it possible to lazy
load columns (not just collections), which would make stuff like
ClobStringType a lot more useful. Right now if you have a table with a
LOB column and use something like ClobStringType you pay the price and
load it even if you don't need it.

Oh well...




-------------------------------------------------------
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