springframework-developer — Spring Framework developers list

[Springframework-developer] Assigning fixed value from a hidden form element

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

Is there a convenient way to assign a fixed value from a hidden form
element and have it bound to the command object?  I'm using the new <form>
tags.

the <form:hidden> tag does not have a value attribute.

Tried to mix in a <spring:bind> tag but this resulted in the preperty
being set to null on the command object even though it originally had a
value pre-assigned when the command object was created.

Can we mix and match <form:> and <spring:bind> tags?

Here is a simplified version of what I'm using:

<h4>New Login Account</h4>

<form:form commandName="command" action="new_user.htm">
<table>
    <tr>
        <td class="prompt">Login ID:</td><td class="value">
            <form:input path="user.userName"/>
        </td>
    </tr>
    <tr class="even">
        <td class="prompt">Password:</td><td class="value">
            <form:password path="user.password"/>
        </td>
        <td>Retype Password:</td><td class="value">
            <form:password path="user.retypePassword"/>
        </td>
    </tr>
</table>

<table>
    <tr>
        <td class="submit"><input name="_eventId_submit" type="submit"
value="NEXT"/></td>
    </tr>
</table>

<spring:bind path="command.step">
    <input type="hidden" name="_step" value="STEP1"/>
</spring:bind>
<input type="hidden" name="_flowExecutionKey" value="${flowExecutionKey}"/>

</form:form>

The "command.step" is the property that I want to be able to set to a
fixed value from the form, like STEP1 in the example.

Thomas

[Springframework-developer] Spring build.85 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

Re: [Springframework-developer] HandlerInterceptor is a misleadingname

[Juergen H. <ju...@in...>]

HandlerInterceptor has actually been around for years, so I'm afraid it's
not as easy to rename. I'm not too bothered with the present name either,
though.

I'm still open to adding a view exception callback to
HandlerExceptionResolver. You do have a point that if we have
afterCompletion in HandlerInterceptor, we can just as well add a
resolveViewException method (or the like) to HandlerExceptionResolver.

One further issue to consider here is that a handler is actually allowed to
write the view to the response directly and return null as ModelAndView. The
present HandlerExceptionResolver can't forward to an error view here either,
similar to the situation of an exception during JSP rendering.

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Matt Sgarlata
Sent: Monday, July 24, 2006 4:00 PM
To: spr...@li...
Subject: Re: [Springframework-developer] HandlerInterceptor is a
misleadingname

Yeah, the response may already be screwed up, but there's still the
potential to log the error or email the sys admin.  I implemented this
functionality in my app very easily as follows

public class ViewExceptionInterceptor extends HandlerInterceptorAdapter {

   private static final Logger logger =
Logger.getLogger(ViewExceptionInterceptor.class);

   public void afterCompletion(HttpServletRequest request,
HttpServletResponse response, Object handler, Exception ex) throws Exception
{
     if (ex != null) {
       logger.error("Error while rendering view", ex);
     }

     super.afterCompletion(request, response, handler, ex);
   }

}


I just posted this on dev because I thought if there's ever a time to
reconsider the name for HandlerInterceptor it's now, since AFAIK the
interface is new in Spring 2, and Spring 2 hasn't technically been released
yet.  RequestInterceptor or WebInterceptor might be a better name.

Matt

Juergen Hoeller wrote:
> Point taken, Matt.
> 
> I'm not opposed to adding callback support for view exceptions. 
> However, we can't get rid of the issue that a view exception will 
> usually lead into a situation where we can't render a proper error 
> page anymore, since we already sent part of the original response to the
client...
> 
> Juergen
>  
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of Matt Sgarlata
> Sent: Friday, July 21, 2006 9:36 PM
> To: spr...@li...
> Subject: [Springframework-developer] HandlerInterceptor is a 
> misleading name
> 
> HandlerInterceptors actually intercept both handlers and views, 
> whereas HandlerExceptionResolvers only resolve exceptions for 
> handlers.  Just wanted to point this out...
> 
> Matt
> 
> 
> ----------------------------------------------------------------------
> --- Take Surveys. Earn Cash. Influence the Future of IT Join 
> SourceForge.net's Techsay panel and you'll get the chance to share 
> your opinions on IT & business topics through brief surveys -- and 
> earn cash 
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEV
> DEV _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> ----------------------------------------------------------------------
> --- Take Surveys. Earn Cash. Influence the Future of IT Join 
> SourceForge.net's Techsay panel and you'll get the chance to share 
> your opinions on IT & business topics through brief surveys -- and 
> earn cash 
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEV
> DEV


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's
Techsay panel and you'll get the chance to share your opinions on IT &
business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] HandlerInterceptor is a misleading name

[Colin Y. <col...@gm...>]

Matt,

HandlerInterceptor (
http://www.springframework.org/docs/api/org/springframework/web/servlet/HandlerInterceptor.html)
has been around for quite a long time and I am sure a lot of people are
using it.  Outright removal of this interface (i.e. by renaming) would cause
a world of pain ;)

Col

On 24/07/06, Matt Sgarlata <mat...@sp...> wrote:
>
> Yeah, the response may already be screwed up, but there's still the
> potential to log the error or email the sys admin.  I implemented this
> functionality in my app very easily as follows
>
> public class ViewExceptionInterceptor extends HandlerInterceptorAdapter {
>
>    private static final Logger logger =
> Logger.getLogger(ViewExceptionInterceptor.class);
>
>    public void afterCompletion(HttpServletRequest request,
> HttpServletResponse response, Object handler, Exception ex) throws
> Exception {
>      if (ex != null) {
>        logger.error("Error while rendering view", ex);
>      }
>
>      super.afterCompletion(request, response, handler, ex);
>    }
>
> }
>
>
> I just posted this on dev because I thought if there's ever a time to
> reconsider the name for HandlerInterceptor it's now, since AFAIK the
> interface is new in Spring 2, and Spring 2 hasn't technically been
> released yet.  RequestInterceptor or WebInterceptor might be a better
> name.
>
> Matt
>
> Juergen Hoeller wrote:
> > Point taken, Matt.
> >
> > I'm not opposed to adding callback support for view exceptions. However,
> we
> > can't get rid of the issue that a view exception will usually lead into
> a
> > situation where we can't render a proper error page anymore, since we
> > already sent part of the original response to the client...
> >
> > Juergen
> >
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On
> Behalf
> > Of Matt Sgarlata
> > Sent: Friday, July 21, 2006 9:36 PM
> > To: spr...@li...
> > Subject: [Springframework-developer] HandlerInterceptor is a misleading
> name
> >
> > HandlerInterceptors actually intercept both handlers and views, whereas
> > HandlerExceptionResolvers only resolve exceptions for handlers.  Just
> wanted
> > to point this out...
> >
> > Matt
> >
> >
> >
> -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net
> 's
> > Techsay panel and you'll get the chance to share your opinions on IT &
> > business topics through brief surveys -- and earn cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> > opinions on IT & business topics through brief surveys -- and earn cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] HandlerInterceptor is a misleading name

[Matt S. <mat...@sp...>]

Yeah, the response may already be screwed up, but there's still the 
potential to log the error or email the sys admin.  I implemented this 
functionality in my app very easily as follows

public class ViewExceptionInterceptor extends HandlerInterceptorAdapter {

   private static final Logger logger = 
Logger.getLogger(ViewExceptionInterceptor.class);

   public void afterCompletion(HttpServletRequest request, 
HttpServletResponse response, Object handler, Exception ex) throws 
Exception {
     if (ex != null) {
       logger.error("Error while rendering view", ex);
     }

     super.afterCompletion(request, response, handler, ex);
   }

}


I just posted this on dev because I thought if there's ever a time to 
reconsider the name for HandlerInterceptor it's now, since AFAIK the 
interface is new in Spring 2, and Spring 2 hasn't technically been 
released yet.  RequestInterceptor or WebInterceptor might be a better name.

Matt

Juergen Hoeller wrote:
> Point taken, Matt.
> 
> I'm not opposed to adding callback support for view exceptions. However, we
> can't get rid of the issue that a view exception will usually lead into a
> situation where we can't render a proper error page anymore, since we
> already sent part of the original response to the client...
> 
> Juergen
>  
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Matt Sgarlata
> Sent: Friday, July 21, 2006 9:36 PM
> To: spr...@li...
> Subject: [Springframework-developer] HandlerInterceptor is a misleading name
> 
> HandlerInterceptors actually intercept both handlers and views, whereas
> HandlerExceptionResolvers only resolve exceptions for handlers.  Just wanted
> to point this out...
> 
> Matt
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's
> Techsay panel and you'll get the chance to share your opinions on IT &
> business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[Springframework-developer] Spring build.84 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.83 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

Re: [Springframework-developer] oumam VlzAGRA

[Carlotta A. <al...@ga...>]

=20
VlzAGRA 3 , 33 $
=20
http://www.cikeraviolasexa.com
=20

,

,

,

,

Iron Johns pool for a ceremony of life. The golden balls drift up
through the water and are seized. And each one contains a healthy
happy baby! And grown men believe that nonsense!

[Springframework-developer] Spring build.82 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.81 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

Re: [Springframework-developer] HandlerInterceptor is a misleading name

[Arjen P. <ar...@in...>]

Well, you could figure out if the response has already been rendered  
by calling isCommitted() on the HttpServletResponse. If it isn't, you  
can call reset(), and render a new error page response.

I'm not saying that we should, I'm just showing that there is a  
possibility.

Arjen

On 22-jul-2006, at 12:15, Juergen Hoeller wrote:

> Point taken, Matt.
>
> I'm not opposed to adding callback support for view exceptions.  
> However, we
> can't get rid of the issue that a view exception will usually lead  
> into a
> situation where we can't render a proper error page anymore, since we
> already sent part of the original response to the client...
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On  
> Behalf
> Of Matt Sgarlata
> Sent: Friday, July 21, 2006 9:36 PM
> To: spr...@li...
> Subject: [Springframework-developer] HandlerInterceptor is a  
> misleading name
>
> HandlerInterceptors actually intercept both handlers and views,  
> whereas
> HandlerExceptionResolvers only resolve exceptions for handlers.   
> Just wanted
> to point this out...
>
> Matt
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT Join  
> SourceForge.net's
> Techsay panel and you'll get the chance to share your opinions on IT &
> business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys -- and earn  
> cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] HandlerInterceptor is a misleading name

[Juergen H. <ju...@in...>]

Point taken, Matt.

I'm not opposed to adding callback support for view exceptions. However, we
can't get rid of the issue that a view exception will usually lead into a
situation where we can't render a proper error page anymore, since we
already sent part of the original response to the client...

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Matt Sgarlata
Sent: Friday, July 21, 2006 9:36 PM
To: spr...@li...
Subject: [Springframework-developer] HandlerInterceptor is a misleading name

HandlerInterceptors actually intercept both handlers and views, whereas
HandlerExceptionResolvers only resolve exceptions for handlers.  Just wanted
to point this out...

Matt


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's
Techsay panel and you'll get the chance to share your opinions on IT &
business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Changed behavior fordefault-lazy-init="true" in 2.0 M5

[Bob W. <bw...@po...>]

No, you define it at the root level and it applies to any bean which 
doesn't specifically specify lazy init:

<beans default-lazy-init='true'>

Bob

Eduardo Pereda IV wrote:
> But you have to set that in every bean file, am I right? Is there a 
> way to globaly define it, for example by setting a property?
> I would like something like --Dorg.springframework.default-lazy-init=true
>
> Thanks!
>
>
> On 7/21/06, *Matt Sgarlata* <mat...@sp... 
> <mailto:mat...@sp...>> wrote:
>
>     default-lazy-init="true"
>
>     There's your solution :)
>
>     Matt
>
>     epere4 wrote:
>     >
>     > Juergen Hoeller wrote:
>     >> Lazy initialization on a bean-by-bean basis can for example be
>     used for
>     >> switching between alternatives based on some placeholder in a bean
>     >> reference. That said, I generally agree that lazy loading is
>     not used that
>     >> much in a Spring environment, in particular not in production.
>     And even in
>     >> development, the startup time of an application context usually
>     doesn't
>     >> really matter... at least not the Spring side of it.
>     >>
>     >> Juergen
>     >>
>     >
>     > Hello!
>     >
>     > I disagree, here. It is true that spring's part in startup time
>     will be
>     > small, but if the beans you instantiate are a lot or are somehow
>     complex,
>     > then you end up waiting for a while until your app completes its
>     starting.
>     >
>     > I would like to have some way to make spring lazy instantiate
>     *everything*
>     > by default (at least at development time). The app in the
>     project I am
>     > waiting for has a huge bean's tree and it takes around half a
>     minute to load
>     > them all (and when I am developing, I rarely need to use more
>     than a few of
>     > these beans at a time).
>     >
>     >
>
>
>     -------------------------------------------------------------------------
>     Take Surveys. Earn Cash. Influence the Future of IT
>     Join SourceForge.net's Techsay panel and you'll get the chance to
>     share your
>     opinions on IT & business topics through brief surveys -- and earn
>     cash
>     http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>     <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
>     _______________________________________________
>     Springframework-developer mailing list
>     Spr...@li...
>     <mailto:Spr...@li...>
>     https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ------------------------------------------------------------------------
>
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>   

[Springframework-developer] HandlerInterceptor is a misleading name

[Matt S. <mat...@sp...>]

HandlerInterceptors actually intercept both handlers and views, whereas 
HandlerExceptionResolvers only resolve exceptions for handlers.  Just 
wanted to point this out...

Matt

[Springframework-developer] Spring build.80 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

Re: [Springframework-developer] FileSystemXmlApplicationContext.getResourceByPath

[Brendan G. <bre...@gm...>]

I agree. This has caught all of us out at my current job at one point or
another.

On 7/21/06, Darren Davison <da...@da...> wrote:
>
> On Thu, Jul 20, 2006 at 10:51:55PM -0400, Colin Sampaleanu wrote:
> > historical thing... I picked this up a long long time ago, probably a
> > bit past Spring 1.0, but at that time it was decided that it would not
> > be changed in order to not break backwards compatibility, but it's an
> > unfortunate wart, as people get surprised by it all the time. The one
>
> so would the impending 2.0 release be a good time to change this to the
> behaviour that most would expect?  Of course it won't be backwards
> compatible, but I think those tradeoffs have already been discussed and if
> you can't do stuff like this on a major version release, Spring will end
> up
> carrying this baggage around for ever.
>
> IMO, you can expect some non-BC in a major version change and so long as
> they are prominently documented, it's not so bad.
>
> What does anyone else think?
>
> Regards,
>
> --
> Darren Davison
> Public Key: 0xDD356B0D
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>

Re: [Springframework-developer] FileSystemXmlApplicationContext.getResourceByPath

[Darren D. <da...@da...>]

On Thu, Jul 20, 2006 at 10:51:55PM -0400, Colin Sampaleanu wrote:
> historical thing... I picked this up a long long time ago, probably a=20
> bit past Spring 1.0, but at that time it was decided that it would not=20
> be changed in order to not break backwards compatibility, but it's an=20
> unfortunate wart, as people get surprised by it all the time. The one=20

so would the impending 2.0 release be a good time to change this to the
behaviour that most would expect?  Of course it won't be backwards
compatible, but I think those tradeoffs have already been discussed and if
you can't do stuff like this on a major version release, Spring will end up
carrying this baggage around for ever.

IMO, you can expect some non-BC in a major version change and so long as
they are prominently documented, it's not so bad.

What does anyone else think?

Regards,

--=20
Darren Davison
Public Key: 0xDD356B0D

Re: [Springframework-developer] Changed behavior fordefault-lazy-init="true" in 2.0 M5

[Eduardo P. I. <ep...@gm...>]

But you have to set that in every bean file, am I right? Is there a way to
globaly define it, for example by setting a property?
I would like something like --Dorg.springframework.default-lazy-init=true

Thanks!


On 7/21/06, Matt Sgarlata <mat...@sp...> wrote:
>
> default-lazy-init="true"
>
> There's your solution :)
>
> Matt
>
> epere4 wrote:
> >
> > Juergen Hoeller wrote:
> >> Lazy initialization on a bean-by-bean basis can for example be used for
> >> switching between alternatives based on some placeholder in a bean
> >> reference. That said, I generally agree that lazy loading is not used
> that
> >> much in a Spring environment, in particular not in production. And even
> in
> >> development, the startup time of an application context usually doesn't
> >> really matter... at least not the Spring side of it.
> >>
> >> Juergen
> >>
> >
> > Hello!
> >
> > I disagree, here. It is true that spring's part in startup time will be
> > small, but if the beans you instantiate are a lot or are somehow
> complex,
> > then you end up waiting for a while until your app completes its
> starting.
> >
> > I would like to have some way to make spring lazy instantiate
> *everything*
> > by default (at least at development time). The app in the project I am
> > waiting for has a huge bean's tree and it takes around half a minute to
> load
> > them all (and when I am developing, I rarely need to use more than a few
> of
> > these beans at a time).
> >
> >
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Changed behavior fordefault-lazy-init="true" in 2.0 M5

[Matt S. <mat...@sp...>]

default-lazy-init="true"

There's your solution :)

Matt

epere4 wrote:
> 
> Juergen Hoeller wrote:
>> Lazy initialization on a bean-by-bean basis can for example be used for
>> switching between alternatives based on some placeholder in a bean
>> reference. That said, I generally agree that lazy loading is not used that
>> much in a Spring environment, in particular not in production. And even in
>> development, the startup time of an application context usually doesn't
>> really matter... at least not the Spring side of it.
>>  
>> Juergen
>>
> 
> Hello!
> 
> I disagree, here. It is true that spring's part in startup time will be
> small, but if the beans you instantiate are a lot or are somehow complex,
> then you end up waiting for a while until your app completes its starting.
> 
> I would like to have some way to make spring lazy instantiate *everything*
> by default (at least at development time). The app in the project I am
> waiting for has a huge bean's tree and it takes around half a minute to load
> them all (and when I am developing, I rarely need to use more than a few of
> these beans at a time).
> 
> 

Re: [Springframework-developer] FileSystemXmlApplicationContext.getResourceByPath

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

Btw, unfortunately the fact that FileSystemXmlApplicationContext treats 
what should be absolute (starting with a leading /) as relative is a 
historical thing... I picked this up a long long time ago, probably a 
bit past Spring 1.0, but at that time it was decided that it would not 
be changed in order to not break backwards compatibility, but it's an 
unfortunate wart, as people get surprised by it all the time. The one 
solution is to use a file: url, which will force the use of a 
UrlResource, instead of an unprefixed resource path, which will end up 
uisng a FileSystemResource, exhibiting this behaviour...

Colin

On 7/17/2006 5:26 AM, Colin Yates wrote:

> Jason,
>
> I noticed this myself and created a JIRA a while ago: 
> http://opensource.atlassian.com/projects/spring/browse/SPR-1884.
>
> Col
>
> On 17/07/06, *Jason W. Solinsky* <jso...@co... 
> <mailto:jso...@co...>> wrote:
>
>     Method getResourceByPath in FileSystemXmlApplicationContext strips
>     leading
>     "/" from paths before loading the resource (in this case the
>     context file).
>
>     The java docs explain this behavior as follows:
>
>     "Note: Even if a given path starts with a slash, it will get
>     interpreted as
>     relative to the current VM working directory. This is consistent
>     with the
>     semantics in a Servlet container."
>
>     Shouldn't servlet specific semantics be implemented by servlet
>     specific
>     classes? (Note that the WebApplicationContexts do not appear to extend
>     FileSystemXmlApplicationContext [anymore?]).
>
>     As a consequence of this behavior, Unix paths beginning with "/"
>     become
>     relative, but Windows paths beginning in "C:\" remain absolute. We
>     have
>     temporarily gotten around this by inserting an extra "/" in front
>     of every
>     path that we use to configure the FileSystemXmlApplicationContext,
>     but this
>     seems like a horrible hack.
>
>     Thanks to Spring's wonderful design, we can easily create our own
>     subclass
>     that avoids this behavior, but shouldn't the servlet specific
>     functionality
>     be removed from this method altogether?
>
>     Thanks,
>
>     JWS
>
>
>
>     -------------------------------------------------------------------------
>
>     Using Tomcat but need to do more? Need to support web services,
>     security?
>     Get stuff done quickly with pre-integrated technology to make your
>     job easier
>     Download IBM WebSphere Application Server v.1.0.1 based on Apache
>     Geronimo
>     http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>     <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
>     _______________________________________________
>     Springframework-developer mailing list
>     Spr...@li...
>     <mailto:Spr...@li...>
>     https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>------------------------------------------------------------------------
>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

Re: [Springframework-developer] Changed behavior fordefault-lazy-init="true" in 2.0 M5

[epere4 <ep...@ya...>]

Juergen Hoeller wrote:
> 
> Lazy initialization on a bean-by-bean basis can for example be used for
> switching between alternatives based on some placeholder in a bean
> reference. That said, I generally agree that lazy loading is not used that
> much in a Spring environment, in particular not in production. And even in
> development, the startup time of an application context usually doesn't
> really matter... at least not the Spring side of it.
>  
> Juergen
> 

Hello!

I disagree, here. It is true that spring's part in startup time will be
small, but if the beans you instantiate are a lot or are somehow complex,
then you end up waiting for a while until your app completes its starting.

I would like to have some way to make spring lazy instantiate *everything*
by default (at least at development time). The app in the project I am
waiting for has a huge bean's tree and it takes around half a minute to load
them all (and when I am developing, I rarely need to use more than a few of
these beans at a time).


-- 
View this message in context: http://www.nabble.com/Changed-behavior-for-default-lazy-init%3Dtrue-in-2.0-M5-tf1768373.html#a5426543
Sent from the springframework-developer forum at Nabble.com.

[Springframework-developer] Spring build.79 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.78 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.77 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.76 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).