springframework-developer — Spring Framework developers list

Re: [Springframework-developer] wrapping an interceptor and Hibernate specific TransactionProxyFactoryBean

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

Jürgen,

(Now that you are back I can write some more 'frivolous' emails :-) ).

W/regards to adding additional interceptor support to 
TransactionProxyFactoryBean, I'm not sure I fully agree that it's 
inherently better or 'cleaner' to apply these to transactional methods 
only. That is, when thinking, 'what is TransactionProxyFactoryBean (in 
this modified version)?', you could consider it as a variant of 
ProxyFactoryBean that implicitly applies a Transaction interceptor 
(before, after, or in between other interceptors, as we decide makes the 
most sense). Those other interceptors can themselves decide if they 
apply, as with ProxyFactoryBean...

There is a usecase for calling Hibernate code (needing a session), 
without needing transactions, and that's mostly for read-only data 
(where there is no need for isolation provided by a transaction). I 
realize that I could just use a regular ProxyFactoryBean, but this is 
all about reducing by maybe 40-50% a bunch of almost identical context 
config data to set up the interceptors. In a decent size app, this is a 
lot of extra typing and maintenance. If the additional interceptors 
applied to only transactional methods, then you would on a case by case 
method have to decide whether or not to use ProxyFactoryBean or 
TransactionProxyFactory, or else always use the 'supports' transaction 
attribute, which doesn't seem that clean to me.

Regards,
Colin

jürgen höller [werk3AT] wrote:

>Hi Colin,
> 
>Your issue is caused by the reliance of your Hibernate access code on HibernateInterceptor for correct resource opening and closing. You should apply HibernateInterceptor even when using HibernateTransactionManager, to be able to switch to JtaTransactionManager without hassle.
> 
>Note that when using HibernateTemplate with allowCreate=true (the default), a new Session will automatically enlist itself with the transaction synchronization capabilities of JtaTransactionManager: It will be created on first access, reused throughout the current transaction, and closed on transaction completion. This guarantees correct JVM-level read-write caching with JTA, and seamless switching between HibernateTransactionManager and JtaTransactionManager.
> 
>In your case, I would indeed have suggested to go the standard ProxyFactoryBean route and apply a HibernateInterceptor after the TransactionInterceptor (after is semantically clearer than before, IMO). ProxyFactoryBean is the correct choice for applying multiple interceptors. TransactionProxyFactoryBean is just meant for declarative transaction management without worrying about AOP concepts.
> 
>Obviously, TransactionProxyFactoryBean could be extended to support additional interceptors for its target bean. I would restrict this to transactional methods though: Executing other methods with a Hibernate Session is really not the task of TransactionProxyFactory Bean - I consider a generic ProxyFactoryBean appropriate here. And you can always define methods as transactional but with propagation "supports" instead of "required".
> 
>Such a hook in TransactionProxyFactoryBean should probably be modelled as "additionalInterceptors" property, taking a list of Interceptor instances, getting applied after the implicit TransactionInterceptor for transactional methods. This can take a HibernateInterceptor or JdoInterceptor or the like. Again, an additional HibernateInterceptors doesn't hurt even with HibernateTransactionManager - it will simply participate in the existing thread-binding.
> 
>Juergen
> 
>
>	-----Original Message----- 
>	From: Colin Sampaleanu [mailto:col...@ex...] 
>	Sent: Thu 9/4/2003 11:10 PM 
>	To: spr...@li... 
>	Cc: 
>	Subject: [Springframework-developer] wrapping an interceptor and Hibernate specific TransactionProxyFactoryBean
>	
>	
>
>	I was using the TransactionProxyFactoryBean with the
>	HibernateTransactionManager, but when I switched to the
>	JTATransactionManager, got bitten by the fact that I no longer had
>	anything creating a Hibernate session and binding it to the current
>	thread, as HibernateTransactionManager used to do by default.
>	
>	One verbose solution would have been to have gone back to the old
>	ProxyFactoryBean mechanism for handling transactions, and just stack a
>	HibernateInterceptor in front of the transaction interceptor.
>	
>	I decided instead to make a Hibernate specific verison of
>	TransactionProxyFactoryBean. All it does is take a new
>	HibernateInterceptor property, and in afterPropertiesSet add the
>	interceptor before the transaction one (however, unlike the transaction
>	one, it will execute on all invocations, since you may want to run some
>	methods with a hibernate session, but no transactions.
>	        // allways invoke the Hibernate Interceptor
>	        addInterceptor(hibernateInterceptor);
>	        ... existing code to set up the Transaction interceptor
>	
>	Now my questions:
>	1: is it worth checking something like this in? I made a cut and past
>	copy of TransactionProxyFactoryBean, and added the new property and
>	modified the afterPropertiesSet. Obviously, I could also have just
>	subclasses the existing class and overriden afterPropertiesSet. That's
>	probably a better choice, but maybe a bit more dangerous if something
>	changes in the parent method which is no longer called at all.
>	2: is there a better way of doing this? I supposed I could have wrapped
>	the proxy in another proxy to add the hibernate interceptor. This would
>	not have required any code changes, but would have made for a lot more
>	typing in the context.  Another option would be to add optional before
>	and after, 'always invoke' interceptor properties to the
>	TransactionProxyFactoryBean, so something like this can be added.
>	
>	Regards,
>	Colin
>	
>

RE: [Springframework-developer] Multipart File Handling

[Trevor C. <pr...@se...>]

You will have complete control over how this is handled.  With the =
default implementation (which is using commons fileupload) you can =
specify the maximum amount to store in memory, and the maximum to write =
to the file (which is the fallback method).  Basically, by setting =
in-memory low (or to 0), you can avoid using it.  With COS (which we =
will add support for later), there is no in-memory support currently.  =
However configuration options for various "MultipartResolver"'s will =
obviously be different.

As far as a DOS/DDOS attack goes, I'm not sure how much this buys you =
though. But the configuration options will be there.

Trevor

-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...]
Sent: September 28, 2003 3:49 PM
To: Trevor Cook
Cc: j=C3=BCrgen h=C3=B6ller [werk3AT]; al...@jt...; Spring Developers
Subject: Re: [Springframework-developer] Multipart File Handling


I'm sort of clued-out here (not knowing most of the context), but can=20
you guys clarify that this will still be able to handle file uploads=20
where the entier file doesn't have to reside entirely in memory? I=20
consider this critical for scalability and being able to handle DOS=20
attacks...

Regards,
Colin

Trevor Cook wrote:

>I think byte[] should work in most cases, and is simple enough to do.  =
However, it does not provide certain features necessary if you are using =
"File" objects (such as size, etc.), and I don't think anyone want's the =
MultipartFile in their form beans.
>
>I have some ideas floating around on how to handle this, but they're =
still a little fuzzy.  Some code/test cycles should figure them out.  =
I'll be working on it this afternoon, so I'll send out more info once I =
have some concrete suggestions.
>
>Trevor
>
>
>-----Original Message-----
>From: j=C3=BCrgen h=C3=B6ller [werk3AT] =
[mailto:jue...@we...]
>Sent: September 28, 2003 10:20 AM
>To: al...@jt...; Trevor Cook; Spring Developers
>Subject: Re: [Springframework-developer] Multipart File Handling
>
>
>Alef,
>=20
>I'm not keen on introducing yet another converter interface, especially =
as there's hardly any variation possible in terms of file upload =
handling. I agree though that having MultipartFile in the object model =
isn't desirable.
>=20
>What about writing the automatic check in ServletRequestDataBinder so =
that it assumes a byte[] for the uploaded file? I can't think of any =
other generic type suitable for uploaded files. java.io.File is no =
candidate as we would need to determine a path to save the file to. I =
consider such persisting the responsibility of the application code =
itself, especially as the uploaded stuff will often be stored to a =
relational database.
>=20
>For anything else than byte[] as property type in a command object, =
even MultipartFile if desired, one can always override onBindAndValidate =
and perform manual binding. Would that be powerful enough for your use =
cases?
>=20
>Juergen
>=20
>=20
>
>	-----Ursprngliche Nachricht-----=20
>	Von: Alef Arendsen (JTeam) [mailto:al...@jt...]=20
>	Gesendet: So 28.09.2003 15:31=20
>	An: j rgen hller [werk3AT]; 'Trevor Cook'; 'Spring Developers'=20
>	Cc:=20
>	Betreff: RE: [Springframework-developer] Multipart File Handling
>=09
>=09
>
>	In one of my previous mails I mentioned doing something like that. It =
involved base64 encoding the byte[] to a String, after which the =
propertyeditor picked it up, decoded it again into a byte[] and set it =
on the object! Arghhh.... (as in wow that's ugly ;-).
>=09
>	I did this, because I rely completely on the mvc framework and 1) did =
not want to put in some MultiPart object in my object model, I just =
wanted a byte[] and 2) just didn't want to make compromises simply =
because of propertyeditors being only capable of handling Strings. Ok, =
the solution is nasty and definitely not up for adding, but I really =
think it should worked in such way that things stay consistent while on =
the other hand, not forcing a user at all to modify stuff in it's =
datamodel... May sound a bit harsh, sorry for that ;-)
>=09
>	Would it be possible to define a simple Spring-proprietary conversion =
interface/class which users can implement themselves capable of =
transforming multpartfile object (or whatever other type) to objects =
defined in a user's datamodel. Something like the following.
>=09
>	class FileUploadConvertor {
>	        public Object convert(MultiPartFile);
>	}
>=09
>	Just some thoughts...
>=09
>	Alef
>=09
>=09
>	-----Oorspronkelijk bericht-----
>	Van: spr...@li... =
[mailto:spr...@li...] Namens j =
rgen hller [werk3AT]
>	Verzonden: Sunday, September 28, 2003 2:31 PM
>	Aan: al...@jt...; Trevor Cook; Spring Developers
>	Onderwerp: Re: [Springframework-developer] Multipart File Handling
>=09
>=09
>	Hi Alef,
>=09
>	A PropertyEditor will always start with a String and convert it to =
some other type, in the web case applied to ServletRequest's =
getParameter values. Here we got MultipartFile instances, retrievable =
via MultipartServletRequest's getFile(String name) method: no Strings in =
the first place, thus the PropertyEditor mechanism is not applicable.
>=09
>	We could possibly add a special check to ServletRequestDataBinder, =
binding MultipartFile instances to respective command bean fields of the =
same type in the case of a multipart request. That would work with any =
MultipartResolver implementation, as it could use the same API as manual =
file upload handling code that casts to MultipartServletRequest.
>=09
>	Definitely a feature worth considering!
>=09
>	Juergen
>=09
>=09
>=09
>	        -----Urspr ngliche Nachricht-----
>	        Von: Alef Arendsen (JTeam) [mailto:al...@jt...]
>	        Gesendet: So 28.09.2003 14:04
>	        An: jrgen h ller [werk3AT]; 'Trevor Cook'; 'Spring Developers'
>	        Cc:
>	        Betreff: RE: [Springframework-developer] Multipart File =
Handling
>	      =20
>	      =20
>=09
>	        Will there be a way - using this solution - to bind the file =
using a propertyeditor (or something else maybe), just as any other =
command object is filled with parameters from the request. For =
consistency, I think that's pretty important to be consistent.
>	      =20
>	        Furthermore I think it's pretty cool if the fileupload could =
be fixed before the 1.0 release! Good thing!
>	      =20
>	        Alef
>	      =20
>	      =20
>	        -----Oorspronkelijk bericht-----
>	        Van: spr...@li... =
[mailto:spr...@li...] Namens =
jrgen h ller [werk3AT]
>	        Verzonden: Sunday, September 28, 2003 12:33 PM
>	        Aan: Trevor Cook; Spring Developers
>	        Onderwerp: Re: [Springframework-developer] Multipart File =
Handling
>	      =20
>	      =20
>	        Hi Trevor,
>	      =20
>	        A MultipartResolver interface with implementations for Commons =
FileUpload and COS is fine with me - it just hadn't high priority since =
I proposed it half a year ago. As I still have a pretty clear picture of =
the issues, I'll be happy to review your code once you've checked it in. =
As this should be pretty straightforward, let's try to include this =
already in 1.0 M2 - at least with a Commons FileUpload implementation.
>	      =20
>	        BTW, in contrast to COS, Commons FileUpload doesn't provide a =
Servlet 2.3 filter anyway. This means that there would be some =
infrastructure code to write for that use case too, even when using =
standard filters. A simple but convenient Spring solution would =
definitely be a good thing.
>	      =20
>	        Juergen
>	      =20
>	      =20
>	      =20
>	      =20
>	                -----Ursprngliche Nachricht-----
>	                Von: Trevor Cook [mailto:pr...@se...]
>	                Gesendet: Sa 27.09.2003 19:35
>	                An: Spring Developers
>	                Cc:
>	                Betreff: [[W3-SPAM]] - [Springframework-developer] =
Multipart File Handling - Email found in subject
>	             =20
>	             =20
>	      =20
>	                First some history:
>	                =
http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279
>	                =
http://sourceforge.net/mailarchive/message.php?msg_id=3D5175276
>	                =
http://sourceforge.net/mailarchive/forum.php?thread_id=3D3125561&forum_id=
=3D3028
>	                7
>	                =
http://sourceforge.net/mailarchive/message.php?msg_id=3D6062288
>	             =20
>	                To address a few things Juergen mentioned previously.
>	             =20
>	                >> a less intrusive way would be to wrap the =
HttpServletRequest via a filter
>	                I personally don't like the filter approach, at least =
for the framework.  It
>	                requires additional setup for the user (in the web.xml =
file) and might be
>	                less understandable since our normal strategy so far =
has been with resolvers
>	                inside the servlet.
>	             =20
>	                >>we would need to find concrete requirements for this
>	                We have numerous uses for file upload handling.  We =
have a public photo
>	                contest where users can upload fotos.  We have special =
access for suppliers
>	                to upload product files (csv) which we then add in to =
our ordering system.
>	                Finally, we have a web administration interface which =
allows our client to
>	                upload files to the website so they can be downloaded. =
 I think that
>	                including this support (multipart handling) is a =
no-brainer.
>	             =20
>	                Basically, I have used COS exclusively in our =
projects, but I don't think
>	                that's easy for Spring to use (due to the licensing).  =
I would simply code
>	                this according to Spring norms using an interface and =
a default version
>	                using Commons FileUpload.  Later, if somebody wants to =
create a cos version
>	                we can (but to be honest, if we have a working, =
integrated solution I'm not
>	                sure that is necessary - at least not in the Spring =
framework).  Basically,
>	                provide hooks and a default implementation, and allow =
users to adopt as
>	                necessary.
>	             =20
>	                In our project we had modified the AbstractController =
and put the code into
>	                it to handle the multipart processing, returning a =
wrapped
>	                HttpServletRequest through the handlers.  This is very =
similiar to Juergen's
>	                outline =
(http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279).
>	             =20
>	                Since we are migrating to the current Spring codebase, =
I need to move our
>	                multipart handling code.  The main question is whether =
we keep it
>	                internally, or place it into Spring.  I propose =
modifying
>	                org.springframework.web.servlet.DispatcherServlet to =
have a
>	                "MultipartResolver".  In the DispatcherServlet, the =
resolver would be called
>	                to wrap the request in doService immediately before =
getHandler(request) -
>	                currently line 351, and then called to do any cleanup =
immediately before
>	                exiting the doService method.
>	             =20
>	                I have about 2/3 of the code already written, and I =
will be writing the rest
>	                between now and Monday.  Does this strategy sound =
appropriate for Spring
>	                (meaning should I commit it to the Spring codebase) =
when it's finished?
>	             =20
>	                Trevor D. Cook
>	                Interprise Software
>	             =20
>

Re: [Springframework-developer] Multipart File Handling

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

I'm sort of clued-out here (not knowing most of the context), but can 
you guys clarify that this will still be able to handle file uploads 
where the entier file doesn't have to reside entirely in memory? I 
consider this critical for scalability and being able to handle DOS 
attacks...

Regards,
Colin

Trevor Cook wrote:

>I think byte[] should work in most cases, and is simple enough to do.  However, it does not provide certain features necessary if you are using "File" objects (such as size, etc.), and I don't think anyone want's the MultipartFile in their form beans.
>
>I have some ideas floating around on how to handle this, but they're still a little fuzzy.  Some code/test cycles should figure them out.  I'll be working on it this afternoon, so I'll send out more info once I have some concrete suggestions.
>
>Trevor
>
>
>-----Original Message-----
>From: jürgen höller [werk3AT] [mailto:jue...@we...]
>Sent: September 28, 2003 10:20 AM
>To: al...@jt...; Trevor Cook; Spring Developers
>Subject: Re: [Springframework-developer] Multipart File Handling
>
>
>Alef,
> 
>I'm not keen on introducing yet another converter interface, especially as there's hardly any variation possible in terms of file upload handling. I agree though that having MultipartFile in the object model isn't desirable.
> 
>What about writing the automatic check in ServletRequestDataBinder so that it assumes a byte[] for the uploaded file? I can't think of any other generic type suitable for uploaded files. java.io.File is no candidate as we would need to determine a path to save the file to. I consider such persisting the responsibility of the application code itself, especially as the uploaded stuff will often be stored to a relational database.
> 
>For anything else than byte[] as property type in a command object, even MultipartFile if desired, one can always override onBindAndValidate and perform manual binding. Would that be powerful enough for your use cases?
> 
>Juergen
> 
> 
>
>	-----Ursprngliche Nachricht----- 
>	Von: Alef Arendsen (JTeam) [mailto:al...@jt...] 
>	Gesendet: So 28.09.2003 15:31 
>	An: j rgen hller [werk3AT]; 'Trevor Cook'; 'Spring Developers' 
>	Cc: 
>	Betreff: RE: [Springframework-developer] Multipart File Handling
>	
>	
>
>	In one of my previous mails I mentioned doing something like that. It involved base64 encoding the byte[] to a String, after which the propertyeditor picked it up, decoded it again into a byte[] and set it on the object! Arghhh.... (as in wow that's ugly ;-).
>	
>	I did this, because I rely completely on the mvc framework and 1) did not want to put in some MultiPart object in my object model, I just wanted a byte[] and 2) just didn't want to make compromises simply because of propertyeditors being only capable of handling Strings. Ok, the solution is nasty and definitely not up for adding, but I really think it should worked in such way that things stay consistent while on the other hand, not forcing a user at all to modify stuff in it's datamodel... May sound a bit harsh, sorry for that ;-)
>	
>	Would it be possible to define a simple Spring-proprietary conversion interface/class which users can implement themselves capable of transforming multpartfile object (or whatever other type) to objects defined in a user's datamodel. Something like the following.
>	
>	class FileUploadConvertor {
>	        public Object convert(MultiPartFile);
>	}
>	
>	Just some thoughts...
>	
>	Alef
>	
>	
>	-----Oorspronkelijk bericht-----
>	Van: spr...@li... [mailto:spr...@li...] Namens j rgen hller [werk3AT]
>	Verzonden: Sunday, September 28, 2003 2:31 PM
>	Aan: al...@jt...; Trevor Cook; Spring Developers
>	Onderwerp: Re: [Springframework-developer] Multipart File Handling
>	
>	
>	Hi Alef,
>	
>	A PropertyEditor will always start with a String and convert it to some other type, in the web case applied to ServletRequest's getParameter values. Here we got MultipartFile instances, retrievable via MultipartServletRequest's getFile(String name) method: no Strings in the first place, thus the PropertyEditor mechanism is not applicable.
>	
>	We could possibly add a special check to ServletRequestDataBinder, binding MultipartFile instances to respective command bean fields of the same type in the case of a multipart request. That would work with any MultipartResolver implementation, as it could use the same API as manual file upload handling code that casts to MultipartServletRequest.
>	
>	Definitely a feature worth considering!
>	
>	Juergen
>	
>	
>	
>	        -----Urspr ngliche Nachricht-----
>	        Von: Alef Arendsen (JTeam) [mailto:al...@jt...]
>	        Gesendet: So 28.09.2003 14:04
>	        An: jrgen h ller [werk3AT]; 'Trevor Cook'; 'Spring Developers'
>	        Cc:
>	        Betreff: RE: [Springframework-developer] Multipart File Handling
>	       
>	       
>	
>	        Will there be a way - using this solution - to bind the file using a propertyeditor (or something else maybe), just as any other command object is filled with parameters from the request. For consistency, I think that's pretty important to be consistent.
>	       
>	        Furthermore I think it's pretty cool if the fileupload could be fixed before the 1.0 release! Good thing!
>	       
>	        Alef
>	       
>	       
>	        -----Oorspronkelijk bericht-----
>	        Van: spr...@li... [mailto:spr...@li...] Namens jrgen h ller [werk3AT]
>	        Verzonden: Sunday, September 28, 2003 12:33 PM
>	        Aan: Trevor Cook; Spring Developers
>	        Onderwerp: Re: [Springframework-developer] Multipart File Handling
>	       
>	       
>	        Hi Trevor,
>	       
>	        A MultipartResolver interface with implementations for Commons FileUpload and COS is fine with me - it just hadn't high priority since I proposed it half a year ago. As I still have a pretty clear picture of the issues, I'll be happy to review your code once you've checked it in. As this should be pretty straightforward, let's try to include this already in 1.0 M2 - at least with a Commons FileUpload implementation.
>	       
>	        BTW, in contrast to COS, Commons FileUpload doesn't provide a Servlet 2.3 filter anyway. This means that there would be some infrastructure code to write for that use case too, even when using standard filters. A simple but convenient Spring solution would definitely be a good thing.
>	       
>	        Juergen
>	       
>	       
>	       
>	       
>	                -----Ursprngliche Nachricht-----
>	                Von: Trevor Cook [mailto:pr...@se...]
>	                Gesendet: Sa 27.09.2003 19:35
>	                An: Spring Developers
>	                Cc:
>	                Betreff: [[W3-SPAM]] - [Springframework-developer] Multipart File Handling - Email found in subject
>	              
>	              
>	       
>	                First some history:
>	                http://sourceforge.net/mailarchive/message.php?msg_id=3891279
>	                http://sourceforge.net/mailarchive/message.php?msg_id=5175276
>	                http://sourceforge.net/mailarchive/forum.php?thread_id=3125561&forum_id=3028
>	                7
>	                http://sourceforge.net/mailarchive/message.php?msg_id=6062288
>	              
>	                To address a few things Juergen mentioned previously.
>	              
>	                >> a less intrusive way would be to wrap the HttpServletRequest via a filter
>	                I personally don't like the filter approach, at least for the framework.  It
>	                requires additional setup for the user (in the web.xml file) and might be
>	                less understandable since our normal strategy so far has been with resolvers
>	                inside the servlet.
>	              
>	                >>we would need to find concrete requirements for this
>	                We have numerous uses for file upload handling.  We have a public photo
>	                contest where users can upload fotos.  We have special access for suppliers
>	                to upload product files (csv) which we then add in to our ordering system.
>	                Finally, we have a web administration interface which allows our client to
>	                upload files to the website so they can be downloaded.  I think that
>	                including this support (multipart handling) is a no-brainer.
>	              
>	                Basically, I have used COS exclusively in our projects, but I don't think
>	                that's easy for Spring to use (due to the licensing).  I would simply code
>	                this according to Spring norms using an interface and a default version
>	                using Commons FileUpload.  Later, if somebody wants to create a cos version
>	                we can (but to be honest, if we have a working, integrated solution I'm not
>	                sure that is necessary - at least not in the Spring framework).  Basically,
>	                provide hooks and a default implementation, and allow users to adopt as
>	                necessary.
>	              
>	                In our project we had modified the AbstractController and put the code into
>	                it to handle the multipart processing, returning a wrapped
>	                HttpServletRequest through the handlers.  This is very similiar to Juergen's
>	                outline (http://sourceforge.net/mailarchive/message.php?msg_id=3891279).
>	              
>	                Since we are migrating to the current Spring codebase, I need to move our
>	                multipart handling code.  The main question is whether we keep it
>	                internally, or place it into Spring.  I propose modifying
>	                org.springframework.web.servlet.DispatcherServlet to have a
>	                "MultipartResolver".  In the DispatcherServlet, the resolver would be called
>	                to wrap the request in doService immediately before getHandler(request) -
>	                currently line 351, and then called to do any cleanup immediately before
>	                exiting the doService method.
>	              
>	                I have about 2/3 of the code already written, and I will be writing the rest
>	                between now and Monday.  Does this strategy sound appropriate for Spring
>	                (meaning should I commit it to the Spring codebase) when it's finished?
>	              
>	                Trevor D. Cook
>	                Interprise Software
>	              
>

RE: [Springframework-developer] Slogan

[Trevor C. <pr...@se...>]

You don't like "SPRING-board" :) - This just popped into my head.  I
honestly don't think we can use this sort of slogan unless we create an
animated, talking Spring similiar to MS' paperclip (and NOBODY wants
that)...

I totally agree with the "_whole_ application framework".  I went to my
favorite project naming tool (http://thesaurus.reference.com), and found the
following alternates for "whole":

- complete
- total
- coherent
- collective
- thorough
- exaustive
- sweeping

2 others I really liked were "perfect" and "jackpot" but we probably
shouldn't use those :)  Also based on the emails I just received from
Mark/Rod, maybe either "J2EE application framework" or a combination of
"Java/J2EE application framework" is better (considering the strong J2EE
focus inside Spring)?   Here's a quick paragraph I threw together.  Feel
free to tear it apart and see where we get.

<slogan paragraph>

"Java/J2EE application framework: learn once, use anywhere"
Spring is a complete and coherent framework which allows you to build
Java/J2EE applications simply on top of a stable foundation.

Complete - Spring is complete because it handles all facets of J2EE, not
just web applications or persistence.  Spring provides support for all the
major J2EE areas, including web applications (MVC), JDBC, validation,
transactions, internationalization, configuration ... (add more)... In
addition, Spring's interface-based design makes it easy to plugin other
projects to replace Spring's default implementations.

Coherent - All of Spring's features are built using Spring's IOC (inversion
of control) container.  This makes it easier to configure various pieces of
an application in a consistent way.  It also allows you to create
test-friendly code while eliminating dependancy on Spring references in most
business code.

Simple - Spring's simplicity stems from the consistency mentioned above with
it's IOC and interface-based design.  Once you learn the core concepts of
Spring, you can apply them to any of Spring's other features.  The knowledge
you gain from Spring's web application handling can be applied to
transaction management without an additional steep learning curve.  Just as
Java promises "write once, run anywhere", Spring allows you to "learn once,
use anywhere".

Stable - Spring is committed to test-driven development, and has high test
coverage throughout.  Spring is also based on "real-world" experience from
many enterprise developers which allows it to effectively handle many areas
other frameworks don't even consider.
</slogan paragraph>

Trevor


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: September 28, 2003 12:47 PM
To: Trevor Cook; spr...@li...
Subject: Re: [Springframework-developer] Slogan


>I think a selling feature of Spring is
> that you can learn the way Spring works and apply it to all the pieces,
> rather than learning multiple disparate apis.

Yes, Spring is a philosophy or approach, that's applied in different areas.

> "SPRING-board to J2EE success"
:-(

> "a simple, standard way to develop custom applications"
Better. Although "standard" has a particular meaning (which doesn't apply to
the J2EE "standards" much more than Spring)

> "a solid foundation to build your custom applications on"
Also better

> "learn once, use anywhere"
I like this. Good concept, well expressed. Probably should be part of our
brief paragraph.

I've been thinking about the phrase "application framework". Like
"application server". Spring is a framework for _whole_ application
frameworks. Whereas Struts is a _web_ application framework, Spring is a
_whole_ application framework.  If we could think of some better alternative
to "whole" to go before "application framework"...

Regards,
Rod




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.516 / Virus Database: 313 - Release Date: 01/09/2003

Re: [Springframework-developer] Slogan

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

"Java application framework: learn once, use anywhere"


----- Original Message ----- 
From: "Mark McNally" <mar...@co...>
To: "'Rod Johnson'" <rod...@in...>; "'Trevor Cook'"
<pr...@se...>; <spr...@li...>
Sent: Sunday, September 28, 2003 6:32 PM
Subject: RE: [Springframework-developer] Slogan


> "Comprehensive, cohesive, loosely-coupled java application framework"
> perhaps? Or maybe just "Comprehensive java application framework" or
> even "Java application framework"?
>
> Mark
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Rod Johnson
> Sent: Sunday, September 28, 2003 11:47 AM
> To: Trevor Cook; spr...@li...
> Subject: Re: [Springframework-developer] Slogan
>
> >I think a selling feature of Spring is
> > that you can learn the way Spring works and apply it to all the
> pieces,
> > rather than learning multiple disparate apis.
>
> Yes, Spring is a philosophy or approach, that's applied in different
> areas.
>
> > "SPRING-board to J2EE success"
> :-(
>
> > "a simple, standard way to develop custom applications"
> Better. Although "standard" has a particular meaning (which doesn't
> apply to
> the J2EE "standards" much more than Spring)
>
> > "a solid foundation to build your custom applications on"
> Also better
>
> > "learn once, use anywhere"
> I like this. Good concept, well expressed. Probably should be part of
> our
> brief paragraph.
>
> I've been thinking about the phrase "application framework". Like
> "application server". Spring is a framework for _whole_ application
> frameworks. Whereas Struts is a _web_ application framework, Spring is a
> _whole_ application framework.  If we could think of some better
> alternative
> to "whole" to go before "application framework"...
>
> Regards,
> Rod
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

RE: [Springframework-developer] Slogan

[Mark M. <mar...@co...>]

"Comprehensive, cohesive, loosely-coupled java application framework"
perhaps? Or maybe just "Comprehensive java application framework" or
even "Java application framework"?

Mark

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Rod Johnson
Sent: Sunday, September 28, 2003 11:47 AM
To: Trevor Cook; spr...@li...
Subject: Re: [Springframework-developer] Slogan

>I think a selling feature of Spring is
> that you can learn the way Spring works and apply it to all the
pieces,
> rather than learning multiple disparate apis.

Yes, Spring is a philosophy or approach, that's applied in different
areas.

> "SPRING-board to J2EE success"
:-(

> "a simple, standard way to develop custom applications"
Better. Although "standard" has a particular meaning (which doesn't
apply to
the J2EE "standards" much more than Spring)

> "a solid foundation to build your custom applications on"
Also better

> "learn once, use anywhere"
I like this. Good concept, well expressed. Probably should be part of
our
brief paragraph.

I've been thinking about the phrase "application framework". Like
"application server". Spring is a framework for _whole_ application
frameworks. Whereas Struts is a _web_ application framework, Spring is a
_whole_ application framework.  If we could think of some better
alternative
to "whole" to go before "application framework"...

Regards,
Rod




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Slogan

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

>I think a selling feature of Spring is
> that you can learn the way Spring works and apply it to all the pieces,
> rather than learning multiple disparate apis.

Yes, Spring is a philosophy or approach, that's applied in different areas.

> "SPRING-board to J2EE success"
:-(

> "a simple, standard way to develop custom applications"
Better. Although "standard" has a particular meaning (which doesn't apply to
the J2EE "standards" much more than Spring)

> "a solid foundation to build your custom applications on"
Also better

> "learn once, use anywhere"
I like this. Good concept, well expressed. Probably should be part of our
brief paragraph.

I've been thinking about the phrase "application framework". Like
"application server". Spring is a framework for _whole_ application
frameworks. Whereas Struts is a _web_ application framework, Spring is a
_whole_ application framework.  If we could think of some better alternative
to "whole" to go before "application framework"...

Regards,
Rod

RE: [Springframework-developer] Slogan

[Trevor C. <pr...@se...>]

I think the usefulness of Spring in many areas has contributed to it being
considered "vague".  Because we are an IOC container, and can run standalone
apps, it's hard to pin down.  I think one of the things we need to do is be
upfront that Spring is "built for J2EE".  It can be used in pieces, and for
non-J2EE, but that is it's main focus.  If we make this decision, then I
think it's easier to define what Spring does as a whole, and use the pieces
like IOC/transactions/MVC as "features" rather than the high-level
description.

I've had a number of conversations with my manager recently on the
usefulness of Spring, and whether it's worth the time we've spent (and will
spend) to learn it (and contribute to it).  My response was:
>>As far as using enough of it, it's the core of our framework.  It replaces
all
>>the <internal proprietary framework names>, and a bunch of custom code and
hacks.
>> ... There are also a bunch of features in the current version of Spring
we had
>> to code ourself for our projects (the difference being that they are more
stable
>>and better tested in Spring

If you're doing J2EE, you need the "plumbing".  The question is if you have
the time to write it yourself (and robustly enough).  My statement about
"better-tested" is pretty standard for open-source projects, since they have
a larger user-base.  The fact that you have more developers looking at a
piece of code also makes it more stable.  This is normal, but the difference
is that every project you use requires familiarizing yourself with the api
and developing a certain trust that it is well-written enough to support
your needs.  In certain areas, there are no alternatives, but in others
(like MVC) there are other options.  I think a selling feature of Spring is
that you can learn the way Spring works and apply it to all the pieces,
rather than learning multiple disparate apis.

With these thoughts in mind, I have a few one-liners for consideration
(maybe to use, but also to spark more ideas).

"SPRING-board to J2EE success"
"a simple, standard way to develop custom applications"
"a solid foundation to build your custom applications on"
"learn once, use anywhere"

Trevor D. Cook


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: September 28, 2003 10:01 AM
To: spr...@li...
Subject: [Springframework-developer] Slogan


I was just reading a blog where someone mentioned that they couldn't work
out a single purpose for Spring. (They were interested in IoC so looked also
at PicoContainer.)

While the blogger clearly didn't take the time to find out what Spring
actually does, I think we should try to think about a slogan or maybe a
paragraph that conveys how it all hangs together. It's ironic in that in
comparison with something like PicoContainer, which does only a part of what
Spring does, Spring can seem to lack focus. Whereas in fact it's a focused
solution to meet infrastructure needs of real apps.

Some ideas (for concepts not wording):
- Spring provides _all_ the infrastructure most projects need
- Spring addresses all architectural tiers, whether or not you choose to use
EJB

Btw my ServerSide article should appear on October 14. I'll confirm closer
to the time, so you can watch the thread.

Regards,
Rod




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] DispatcherServlet - no mapping found

[Trevor C. <pr...@se...>]

I've created a "org.springframework.web.servlet.PageNotFound" and changed
the logging level to "warn".  Both are now committed.

Trevor


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: September 28, 2003 11:08 AM
To: Trevor Cook; Spring Developers
Subject: Re: [Springframework-developer] DispatcherServlet - no mapping
found



> I like that idea, but what name do we use for the log?  A simple
> "PageNotFound" name, or a packaged name like
> "org.springframework.web.servlet.PageNotFound".  I favor the latter since
> you could also just have all the web stuff in a single log.

Probably the packaged name. Example log4j config should treat this
distinctly.

> The other question is whether we create a marker interface to show that
> we've used this name for logging?
I don't think we need a marker interface.

Regards,
Rod

Re: [Springframework-developer] DispatcherServlet - no mapping found

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

> I like that idea, but what name do we use for the log?  A simple
> "PageNotFound" name, or a packaged name like
> "org.springframework.web.servlet.PageNotFound".  I favor the latter since
> you could also just have all the web stuff in a single log.

Probably the packaged name. Example log4j config should treat this
distinctly.

> The other question is whether we create a marker interface to show that
> we've used this name for logging?
I don't think we need a marker interface.

Regards,
Rod

Re: [Springframework-developer] Multipart File Handling

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

QmFjayBmcm9tIHZhY2F0aW9uLCBmaW5hbGx5ISBBZnRlciBzbGVlcGluZyBmb3IgdGhlIHdob2xl
IGFmdGVybm9vbiB5ZXN0ZXJkYXkgYW5kIHN0YXlpbmcgdXAgYWxsIG5pZ2h0ICh3ZSBhbGwgbG92
ZSBqZXQgbGFnLCBkb24ndCB3ZT8pLCBJJ20gdHJ5aW5nIHRvIGFwcHJvYWNoIG5vcm1hbCBFdXJv
cGVhbiBkYXkvbmlnaHQgcmh5dGhtIG5vdyA7LSkNCiANClJlZ2FyZGluZyBhIGZpbHRlcjogSWYg
Q29tbW9ucyBGaWxlVXBsb2FkIHdhbnQgYSBmaWx0ZXIsIHRoZXkgc2hvdWxkIGRldmVsb3Agb25l
LiBJZiB3ZSBwcm92aWRlIG91ciBvd24gbXVsdGlwYXJ0IHBhcnNpbmcgaG9va3MsIEkgZG8gbm90
IGNvbnNpZGVyIHN1Y2ggYSBTZXJ2bGV0IDIuMyBmaWx0ZXIgYXMgb3VyIHJlcG9uc2liaWxpdHku
DQogDQpBcyB3ZSBoYXZlIGZpbGUgdXBsb2FkIHJlcXVpcmVtZW50cyBpbiBhbGwgd2VyazNBVCBw
cm9kdWN0cywgSSdsbCByZXZpZXcgeW91ciBzb2x1dGlvbiBwcm9tcHRseSBhbmQgYWRhcHQgb3Vy
IHByb2R1Y3RzIHRvIHRoZW0gYXMgc29vbiBhcyBwb3NzaWJsZS4gQ3VycmVudGx5LCBvbmUgdXNl
cyBtYW51YWwgQ09TIGhhbmRsaW5nIGNvZGUgYW5kIHRoZSBvdGhlciB0d28gbWFudWFsIENvbW1v
bnMgRmlsZVVwbG9hZCB3aXRoaW4gYSBjdXN0b20gU3ByaW5nIGNvbnRyb2xsZXIgaW1wbGVtZW50
YXRpb24uDQogDQpKdWVyZ2VuDQogDQogDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNo
dC0tLS0tIA0KCVZvbjogVHJldm9yIENvb2sgW21haWx0bzpwcmlzZTAzQHNlbnRleC5uZXRdIA0K
CUdlc2VuZGV0OiBTbyAyOC4wOS4yMDAzIDE2OjQwIA0KCUFuOiBqw7xyZ2VuIGjDtmxsZXIgW3dl
cmszQVRdOyBTcHJpbmcgRGV2ZWxvcGVycyANCglDYzogDQoJQmV0cmVmZjogUkU6IFtTcHJpbmdm
cmFtZXdvcmstZGV2ZWxvcGVyXSBNdWx0aXBhcnQgRmlsZSBIYW5kbGluZw0KCQ0KCQ0KDQoJSnVl
cmdlbiAtIEdsYWQgdGhhdCB5b3UnbGwgbG9vayBhdCBpdC4gIEJhc2VkIG9uIHRoZSBwcmV2aW91
cyBlbWFpbHMgeW91IHNlZW0gdG8gaGF2ZSBhIHByZXR0eSBnb29kIGhhbmRsZSBvbiB0aGlzLCBh
bmQgbXkgaWRlYXMgYXJlIGZhaXJseSBjbG9zZSB0byB5b3Vycy4gIEFyZSB5b3UgYmFjayBmcm9t
IHZhY2F0aW9uIG5vdywgb3Igc3RpbGwgY2hlY2tpbmcgcmVtb3RlbHk/DQoJDQoJQXMgZmFyIGFz
IHRoZSBmaWx0ZXIgZ29lcywgdGhhdCBpcyBkZWZpbmF0ZWx5IGEgcG9zc2libGl0eSB0byBhZGQg
bGF0ZXIgKHBvc3NpYmx5IGV2ZW4gZm9yIDEuMCkgYnV0IG5vdCBzb21ldGhpbmcgSSdsbCBiZSBh
YmxlIHRvIGxvb2sgYXQgcmlnaHQgYXdheS4gIEhvd2V2ZXIsIGl0IGNvdWxkIHVzZSB0aGUgc2Ft
ZSBjb2RlLCBzbyBpdCBzaG91bGRuJ3QgYmUgdG9vIGRpZmZpY3VsdC4NCgkNCglUcmV2b3INCgkN
CgkNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCUZyb206IGrDvHJnZW4gaMO2bGxlciBb
d2VyazNBVF0gW21haWx0bzpqdWVyZ2VuLmhvZWxsZXJAd2VyazNhdC5jb21dDQoJU2VudDogU2Vw
dGVtYmVyIDI4LCAyMDAzIDY6MzMgQU0NCglUbzogVHJldm9yIENvb2s7IFNwcmluZyBEZXZlbG9w
ZXJzDQoJU3ViamVjdDogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBNdWx0aXBhcnQg
RmlsZSBIYW5kbGluZw0KCQ0KCQ0KCUhpIFRyZXZvciwNCgkNCglBIE11bHRpcGFydFJlc29sdmVy
IGludGVyZmFjZSB3aXRoIGltcGxlbWVudGF0aW9ucyBmb3IgQ29tbW9ucyBGaWxlVXBsb2FkIGFu
ZCBDT1MgaXMgZmluZSB3aXRoIG1lIC0gaXQganVzdCBoYWRuJ3QgaGlnaCBwcmlvcml0eSBzaW5j
ZSBJIHByb3Bvc2VkIGl0IGhhbGYgYSB5ZWFyIGFnby4gQXMgSSBzdGlsbCBoYXZlIGEgcHJldHR5
IGNsZWFyIHBpY3R1cmUgb2YgdGhlIGlzc3VlcywgSSdsbCBiZSBoYXBweSB0byByZXZpZXcgeW91
ciBjb2RlIG9uY2UgeW91J3ZlIGNoZWNrZWQgaXQgaW4uIEFzIHRoaXMgc2hvdWxkIGJlIHByZXR0
eSBzdHJhaWdodGZvcndhcmQsIGxldCdzIHRyeSB0byBpbmNsdWRlIHRoaXMgYWxyZWFkeSBpbiAx
LjAgTTIgLSBhdCBsZWFzdCB3aXRoIGEgQ29tbW9ucyBGaWxlVXBsb2FkIGltcGxlbWVudGF0aW9u
Lg0KCQ0KCUJUVywgaW4gY29udHJhc3QgdG8gQ09TLCBDb21tb25zIEZpbGVVcGxvYWQgZG9lc24n
dCBwcm92aWRlIGEgU2VydmxldCAyLjMgZmlsdGVyIGFueXdheS4gVGhpcyBtZWFucyB0aGF0IHRo
ZXJlIHdvdWxkIGJlIHNvbWUgaW5mcmFzdHJ1Y3R1cmUgY29kZSB0byB3cml0ZSBmb3IgdGhhdCB1
c2UgY2FzZSB0b28sIGV2ZW4gd2hlbiB1c2luZyBzdGFuZGFyZCBmaWx0ZXJzLiBBIHNpbXBsZSBi
dXQgY29udmVuaWVudCBTcHJpbmcgc29sdXRpb24gd291bGQgZGVmaW5pdGVseSBiZSBhIGdvb2Qg
dGhpbmcuDQoJDQoJSnVlcmdlbg0KCQ0KCQ0KCQ0KCQ0KCSAgICAgICAgLS0tLS1VcnNwcm5nbGlj
aGUgTmFjaHJpY2h0LS0tLS0NCgkgICAgICAgIFZvbjogVHJldm9yIENvb2sgW21haWx0bzpwcmlz
ZTAzQHNlbnRleC5uZXRdDQoJICAgICAgICBHZXNlbmRldDogU2EgMjcuMDkuMjAwMyAxOTozNQ0K
CSAgICAgICAgQW46IFNwcmluZyBEZXZlbG9wZXJzDQoJICAgICAgICBDYzoNCgkgICAgICAgIEJl
dHJlZmY6IFtbVzMtU1BBTV1dIC0gW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIE11bHRpcGFy
dCBGaWxlIEhhbmRsaW5nIC0gRW1haWwgZm91bmQgaW4gc3ViamVjdA0KCSAgICAgICANCgkgICAg
ICAgDQoJDQoJICAgICAgICBGaXJzdCBzb21lIGhpc3Rvcnk6DQoJICAgICAgICBodHRwOi8vc291
cmNlZm9yZ2UubmV0L21haWxhcmNoaXZlL21lc3NhZ2UucGhwP21zZ19pZD0zODkxMjc5DQoJICAg
ICAgICBodHRwOi8vc291cmNlZm9yZ2UubmV0L21haWxhcmNoaXZlL21lc3NhZ2UucGhwP21zZ19p
ZD01MTc1Mjc2DQoJICAgICAgICBodHRwOi8vc291cmNlZm9yZ2UubmV0L21haWxhcmNoaXZlL2Zv
cnVtLnBocD90aHJlYWRfaWQ9MzEyNTU2MSZmb3J1bV9pZD0zMDI4DQoJICAgICAgICA3DQoJICAg
ICAgICBodHRwOi8vc291cmNlZm9yZ2UubmV0L21haWxhcmNoaXZlL21lc3NhZ2UucGhwP21zZ19p
ZD02MDYyMjg4DQoJICAgICAgIA0KCSAgICAgICAgVG8gYWRkcmVzcyBhIGZldyB0aGluZ3MgSnVl
cmdlbiBtZW50aW9uZWQgcHJldmlvdXNseS4NCgkgICAgICAgDQoJICAgICAgICA+PiBhIGxlc3Mg
aW50cnVzaXZlIHdheSB3b3VsZCBiZSB0byB3cmFwIHRoZSBIdHRwU2VydmxldFJlcXVlc3Qgdmlh
IGEgZmlsdGVyDQoJICAgICAgICBJIHBlcnNvbmFsbHkgZG9uJ3QgbGlrZSB0aGUgZmlsdGVyIGFw
cHJvYWNoLCBhdCBsZWFzdCBmb3IgdGhlIGZyYW1ld29yay4gIEl0DQoJICAgICAgICByZXF1aXJl
cyBhZGRpdGlvbmFsIHNldHVwIGZvciB0aGUgdXNlciAoaW4gdGhlIHdlYi54bWwgZmlsZSkgYW5k
IG1pZ2h0IGJlDQoJICAgICAgICBsZXNzIHVuZGVyc3RhbmRhYmxlIHNpbmNlIG91ciBub3JtYWwg
c3RyYXRlZ3kgc28gZmFyIGhhcyBiZWVuIHdpdGggcmVzb2x2ZXJzDQoJICAgICAgICBpbnNpZGUg
dGhlIHNlcnZsZXQuDQoJICAgICAgIA0KCSAgICAgICAgPj53ZSB3b3VsZCBuZWVkIHRvIGZpbmQg
Y29uY3JldGUgcmVxdWlyZW1lbnRzIGZvciB0aGlzDQoJICAgICAgICBXZSBoYXZlIG51bWVyb3Vz
IHVzZXMgZm9yIGZpbGUgdXBsb2FkIGhhbmRsaW5nLiAgV2UgaGF2ZSBhIHB1YmxpYyBwaG90bw0K
CSAgICAgICAgY29udGVzdCB3aGVyZSB1c2VycyBjYW4gdXBsb2FkIGZvdG9zLiAgV2UgaGF2ZSBz
cGVjaWFsIGFjY2VzcyBmb3Igc3VwcGxpZXJzDQoJICAgICAgICB0byB1cGxvYWQgcHJvZHVjdCBm
aWxlcyAoY3N2KSB3aGljaCB3ZSB0aGVuIGFkZCBpbiB0byBvdXIgb3JkZXJpbmcgc3lzdGVtLg0K
CSAgICAgICAgRmluYWxseSwgd2UgaGF2ZSBhIHdlYiBhZG1pbmlzdHJhdGlvbiBpbnRlcmZhY2Ug
d2hpY2ggYWxsb3dzIG91ciBjbGllbnQgdG8NCgkgICAgICAgIHVwbG9hZCBmaWxlcyB0byB0aGUg
d2Vic2l0ZSBzbyB0aGV5IGNhbiBiZSBkb3dubG9hZGVkLiAgSSB0aGluayB0aGF0DQoJICAgICAg
ICBpbmNsdWRpbmcgdGhpcyBzdXBwb3J0IChtdWx0aXBhcnQgaGFuZGxpbmcpIGlzIGEgbm8tYnJh
aW5lci4NCgkgICAgICAgDQoJICAgICAgICBCYXNpY2FsbHksIEkgaGF2ZSB1c2VkIENPUyBleGNs
dXNpdmVseSBpbiBvdXIgcHJvamVjdHMsIGJ1dCBJIGRvbid0IHRoaW5rDQoJICAgICAgICB0aGF0
J3MgZWFzeSBmb3IgU3ByaW5nIHRvIHVzZSAoZHVlIHRvIHRoZSBsaWNlbnNpbmcpLiAgSSB3b3Vs
ZCBzaW1wbHkgY29kZQ0KCSAgICAgICAgdGhpcyBhY2NvcmRpbmcgdG8gU3ByaW5nIG5vcm1zIHVz
aW5nIGFuIGludGVyZmFjZSBhbmQgYSBkZWZhdWx0IHZlcnNpb24NCgkgICAgICAgIHVzaW5nIENv
bW1vbnMgRmlsZVVwbG9hZC4gIExhdGVyLCBpZiBzb21lYm9keSB3YW50cyB0byBjcmVhdGUgYSBj
b3MgdmVyc2lvbg0KCSAgICAgICAgd2UgY2FuIChidXQgdG8gYmUgaG9uZXN0LCBpZiB3ZSBoYXZl
IGEgd29ya2luZywgaW50ZWdyYXRlZCBzb2x1dGlvbiBJJ20gbm90DQoJICAgICAgICBzdXJlIHRo
YXQgaXMgbmVjZXNzYXJ5IC0gYXQgbGVhc3Qgbm90IGluIHRoZSBTcHJpbmcgZnJhbWV3b3JrKS4g
IEJhc2ljYWxseSwNCgkgICAgICAgIHByb3ZpZGUgaG9va3MgYW5kIGEgZGVmYXVsdCBpbXBsZW1l
bnRhdGlvbiwgYW5kIGFsbG93IHVzZXJzIHRvIGFkb3B0IGFzDQoJICAgICAgICBuZWNlc3Nhcnku
DQoJICAgICAgIA0KCSAgICAgICAgSW4gb3VyIHByb2plY3Qgd2UgaGFkIG1vZGlmaWVkIHRoZSBB
YnN0cmFjdENvbnRyb2xsZXIgYW5kIHB1dCB0aGUgY29kZSBpbnRvDQoJICAgICAgICBpdCB0byBo
YW5kbGUgdGhlIG11bHRpcGFydCBwcm9jZXNzaW5nLCByZXR1cm5pbmcgYSB3cmFwcGVkDQoJICAg
ICAgICBIdHRwU2VydmxldFJlcXVlc3QgdGhyb3VnaCB0aGUgaGFuZGxlcnMuICBUaGlzIGlzIHZl
cnkgc2ltaWxpYXIgdG8gSnVlcmdlbidzDQoJICAgICAgICBvdXRsaW5lIChodHRwOi8vc291cmNl
Zm9yZ2UubmV0L21haWxhcmNoaXZlL21lc3NhZ2UucGhwP21zZ19pZD0zODkxMjc5KS4NCgkgICAg
ICAgDQoJICAgICAgICBTaW5jZSB3ZSBhcmUgbWlncmF0aW5nIHRvIHRoZSBjdXJyZW50IFNwcmlu
ZyBjb2RlYmFzZSwgSSBuZWVkIHRvIG1vdmUgb3VyDQoJICAgICAgICBtdWx0aXBhcnQgaGFuZGxp
bmcgY29kZS4gIFRoZSBtYWluIHF1ZXN0aW9uIGlzIHdoZXRoZXIgd2Uga2VlcCBpdA0KCSAgICAg
ICAgaW50ZXJuYWxseSwgb3IgcGxhY2UgaXQgaW50byBTcHJpbmcuICBJIHByb3Bvc2UgbW9kaWZ5
aW5nDQoJICAgICAgICBvcmcuc3ByaW5nZnJhbWV3b3JrLndlYi5zZXJ2bGV0LkRpc3BhdGNoZXJT
ZXJ2bGV0IHRvIGhhdmUgYQ0KCSAgICAgICAgIk11bHRpcGFydFJlc29sdmVyIi4gIEluIHRoZSBE
aXNwYXRjaGVyU2VydmxldCwgdGhlIHJlc29sdmVyIHdvdWxkIGJlIGNhbGxlZA0KCSAgICAgICAg
dG8gd3JhcCB0aGUgcmVxdWVzdCBpbiBkb1NlcnZpY2UgaW1tZWRpYXRlbHkgYmVmb3JlIGdldEhh
bmRsZXIocmVxdWVzdCkgLQ0KCSAgICAgICAgY3VycmVudGx5IGxpbmUgMzUxLCBhbmQgdGhlbiBj
YWxsZWQgdG8gZG8gYW55IGNsZWFudXAgaW1tZWRpYXRlbHkgYmVmb3JlDQoJICAgICAgICBleGl0
aW5nIHRoZSBkb1NlcnZpY2UgbWV0aG9kLg0KCSAgICAgICANCgkgICAgICAgIEkgaGF2ZSBhYm91
dCAyLzMgb2YgdGhlIGNvZGUgYWxyZWFkeSB3cml0dGVuLCBhbmQgSSB3aWxsIGJlIHdyaXRpbmcg
dGhlIHJlc3QNCgkgICAgICAgIGJldHdlZW4gbm93IGFuZCBNb25kYXkuICBEb2VzIHRoaXMgc3Ry
YXRlZ3kgc291bmQgYXBwcm9wcmlhdGUgZm9yIFNwcmluZw0KCSAgICAgICAgKG1lYW5pbmcgc2hv
dWxkIEkgY29tbWl0IGl0IHRvIHRoZSBTcHJpbmcgY29kZWJhc2UpIHdoZW4gaXQncyBmaW5pc2hl
ZD8NCgkgICAgICAgDQoJICAgICAgICBUcmV2b3IgRC4gQ29vaw0KCSAgICAgICAgSW50ZXJwcmlz
ZSBTb2Z0d2FyZQ0KCSAgICAgICANCgkgICAgICAgDQoJICAgICAgIA0KCSAgICAgICAgLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCSAgICAg
ICAgVGhpcyBzZi5uZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OlRoaW5rR2Vlaw0KCSAgICAgICAg
V2VsY29tZSB0byBnZWVrIGhlYXZlbi4NCgkgICAgICAgIGh0dHA6Ly90aGlua2dlZWsuY29tL3Nm
DQoJICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KCSAgICAgICAgU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWlsaW5nIGxpc3QNCgkgICAg
ICAgIFNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJICAg
ICAgICBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdm
cmFtZXdvcmstZGV2ZWxvcGVyDQoJICAgICAgIA0KCQ0KCQ0KCQ0KDQo=

RE: [Springframework-developer] Multipart File Handling

[Trevor C. <pr...@se...>]

I think byte[] should work in most cases, and is simple enough to do.  =
However, it does not provide certain features necessary if you are using =
"File" objects (such as size, etc.), and I don't think anyone want's the =
MultipartFile in their form beans.

I have some ideas floating around on how to handle this, but they're =
still a little fuzzy.  Some code/test cycles should figure them out.  =
I'll be working on it this afternoon, so I'll send out more info once I =
have some concrete suggestions.

Trevor


-----Original Message-----
From: j=C3=BCrgen h=C3=B6ller [werk3AT] =
[mailto:jue...@we...]
Sent: September 28, 2003 10:20 AM
To: al...@jt...; Trevor Cook; Spring Developers
Subject: Re: [Springframework-developer] Multipart File Handling


Alef,
=20
I'm not keen on introducing yet another converter interface, especially =
as there's hardly any variation possible in terms of file upload =
handling. I agree though that having MultipartFile in the object model =
isn't desirable.
=20
What about writing the automatic check in ServletRequestDataBinder so =
that it assumes a byte[] for the uploaded file? I can't think of any =
other generic type suitable for uploaded files. java.io.File is no =
candidate as we would need to determine a path to save the file to. I =
consider such persisting the responsibility of the application code =
itself, especially as the uploaded stuff will often be stored to a =
relational database.
=20
For anything else than byte[] as property type in a command object, even =
MultipartFile if desired, one can always override onBindAndValidate and =
perform manual binding. Would that be powerful enough for your use =
cases?
=20
Juergen
=20
=20

	-----Ursprngliche Nachricht-----=20
	Von: Alef Arendsen (JTeam) [mailto:al...@jt...]=20
	Gesendet: So 28.09.2003 15:31=20
	An: j rgen hller [werk3AT]; 'Trevor Cook'; 'Spring Developers'=20
	Cc:=20
	Betreff: RE: [Springframework-developer] Multipart File Handling
=09
=09

	In one of my previous mails I mentioned doing something like that. It =
involved base64 encoding the byte[] to a String, after which the =
propertyeditor picked it up, decoded it again into a byte[] and set it =
on the object! Arghhh.... (as in wow that's ugly ;-).
=09
	I did this, because I rely completely on the mvc framework and 1) did =
not want to put in some MultiPart object in my object model, I just =
wanted a byte[] and 2) just didn't want to make compromises simply =
because of propertyeditors being only capable of handling Strings. Ok, =
the solution is nasty and definitely not up for adding, but I really =
think it should worked in such way that things stay consistent while on =
the other hand, not forcing a user at all to modify stuff in it's =
datamodel... May sound a bit harsh, sorry for that ;-)
=09
	Would it be possible to define a simple Spring-proprietary conversion =
interface/class which users can implement themselves capable of =
transforming multpartfile object (or whatever other type) to objects =
defined in a user's datamodel. Something like the following.
=09
	class FileUploadConvertor {
	        public Object convert(MultiPartFile);
	}
=09
	Just some thoughts...
=09
	Alef
=09
=09
	-----Oorspronkelijk bericht-----
	Van: spr...@li... =
[mailto:spr...@li...] Namens j =
rgen hller [werk3AT]
	Verzonden: Sunday, September 28, 2003 2:31 PM
	Aan: al...@jt...; Trevor Cook; Spring Developers
	Onderwerp: Re: [Springframework-developer] Multipart File Handling
=09
=09
	Hi Alef,
=09
	A PropertyEditor will always start with a String and convert it to some =
other type, in the web case applied to ServletRequest's getParameter =
values. Here we got MultipartFile instances, retrievable via =
MultipartServletRequest's getFile(String name) method: no Strings in the =
first place, thus the PropertyEditor mechanism is not applicable.
=09
	We could possibly add a special check to ServletRequestDataBinder, =
binding MultipartFile instances to respective command bean fields of the =
same type in the case of a multipart request. That would work with any =
MultipartResolver implementation, as it could use the same API as manual =
file upload handling code that casts to MultipartServletRequest.
=09
	Definitely a feature worth considering!
=09
	Juergen
=09
=09
=09
	        -----Urspr ngliche Nachricht-----
	        Von: Alef Arendsen (JTeam) [mailto:al...@jt...]
	        Gesendet: So 28.09.2003 14:04
	        An: jrgen h ller [werk3AT]; 'Trevor Cook'; 'Spring Developers'
	        Cc:
	        Betreff: RE: [Springframework-developer] Multipart File =
Handling
	      =20
	      =20
=09
	        Will there be a way - using this solution - to bind the file =
using a propertyeditor (or something else maybe), just as any other =
command object is filled with parameters from the request. For =
consistency, I think that's pretty important to be consistent.
	      =20
	        Furthermore I think it's pretty cool if the fileupload could be =
fixed before the 1.0 release! Good thing!
	      =20
	        Alef
	      =20
	      =20
	        -----Oorspronkelijk bericht-----
	        Van: spr...@li... =
[mailto:spr...@li...] Namens =
jrgen h ller [werk3AT]
	        Verzonden: Sunday, September 28, 2003 12:33 PM
	        Aan: Trevor Cook; Spring Developers
	        Onderwerp: Re: [Springframework-developer] Multipart File =
Handling
	      =20
	      =20
	        Hi Trevor,
	      =20
	        A MultipartResolver interface with implementations for Commons =
FileUpload and COS is fine with me - it just hadn't high priority since =
I proposed it half a year ago. As I still have a pretty clear picture of =
the issues, I'll be happy to review your code once you've checked it in. =
As this should be pretty straightforward, let's try to include this =
already in 1.0 M2 - at least with a Commons FileUpload implementation.
	      =20
	        BTW, in contrast to COS, Commons FileUpload doesn't provide a =
Servlet 2.3 filter anyway. This means that there would be some =
infrastructure code to write for that use case too, even when using =
standard filters. A simple but convenient Spring solution would =
definitely be a good thing.
	      =20
	        Juergen
	      =20
	      =20
	      =20
	      =20
	                -----Ursprngliche Nachricht-----
	                Von: Trevor Cook [mailto:pr...@se...]
	                Gesendet: Sa 27.09.2003 19:35
	                An: Spring Developers
	                Cc:
	                Betreff: [[W3-SPAM]] - [Springframework-developer] =
Multipart File Handling - Email found in subject
	             =20
	             =20
	      =20
	                First some history:
	                =
http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279
	                =
http://sourceforge.net/mailarchive/message.php?msg_id=3D5175276
	                =
http://sourceforge.net/mailarchive/forum.php?thread_id=3D3125561&forum_id=
=3D3028
	                7
	                =
http://sourceforge.net/mailarchive/message.php?msg_id=3D6062288
	             =20
	                To address a few things Juergen mentioned previously.
	             =20
	                >> a less intrusive way would be to wrap the =
HttpServletRequest via a filter
	                I personally don't like the filter approach, at least =
for the framework.  It
	                requires additional setup for the user (in the web.xml =
file) and might be
	                less understandable since our normal strategy so far =
has been with resolvers
	                inside the servlet.
	             =20
	                >>we would need to find concrete requirements for this
	                We have numerous uses for file upload handling.  We =
have a public photo
	                contest where users can upload fotos.  We have special =
access for suppliers
	                to upload product files (csv) which we then add in to =
our ordering system.
	                Finally, we have a web administration interface which =
allows our client to
	                upload files to the website so they can be downloaded.  =
I think that
	                including this support (multipart handling) is a =
no-brainer.
	             =20
	                Basically, I have used COS exclusively in our projects, =
but I don't think
	                that's easy for Spring to use (due to the licensing).  =
I would simply code
	                this according to Spring norms using an interface and a =
default version
	                using Commons FileUpload.  Later, if somebody wants to =
create a cos version
	                we can (but to be honest, if we have a working, =
integrated solution I'm not
	                sure that is necessary - at least not in the Spring =
framework).  Basically,
	                provide hooks and a default implementation, and allow =
users to adopt as
	                necessary.
	             =20
	                In our project we had modified the AbstractController =
and put the code into
	                it to handle the multipart processing, returning a =
wrapped
	                HttpServletRequest through the handlers.  This is very =
similiar to Juergen's
	                outline =
(http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279).
	             =20
	                Since we are migrating to the current Spring codebase, =
I need to move our
	                multipart handling code.  The main question is whether =
we keep it
	                internally, or place it into Spring.  I propose =
modifying
	                org.springframework.web.servlet.DispatcherServlet to =
have a
	                "MultipartResolver".  In the DispatcherServlet, the =
resolver would be called
	                to wrap the request in doService immediately before =
getHandler(request) -
	                currently line 351, and then called to do any cleanup =
immediately before
	                exiting the doService method.
	             =20
	                I have about 2/3 of the code already written, and I =
will be writing the rest
	                between now and Monday.  Does this strategy sound =
appropriate for Spring
	                (meaning should I commit it to the Spring codebase) =
when it's finished?
	             =20
	                Trevor D. Cook
	                Interprise Software
	             =20
	             =20
	             =20
	                -------------------------------------------------------
	                This sf.net email is sponsored by:ThinkGeek
	                Welcome to geek heaven.
	                http://thinkgeek.com/sf
	                _______________________________________________
	                Springframework-developer mailing list
	                Spr...@li...
	                =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
	             =20
	      =20
	        N=18 Xu)=19Y g =17  HzGJ jg?z??x? G ?q z m?X (=1E~zw X b??  =
jg?=1Dz??
	      =20
	      =20
=09
	N=18 ?X'u?)=19 Y\g? =17 =7F b?H=1EzG(=1FJ  jg?=1Dz??x%R? (G^?h  lq  =
zm??X (=1E~zw X b??  jg?=1Dz??
=09
=09

RE: [Springframework-developer] Multipart File Handling

[Trevor C. <pr...@se...>]

Juergen - Glad that you'll look at it.  Based on the previous emails you =
seem to have a pretty good handle on this, and my ideas are fairly close =
to yours.  Are you back from vacation now, or still checking remotely?

As far as the filter goes, that is definately a possiblity to add later =
(possibly even for 1.0) but not something I'll be able to look at right =
away.  However, it could use the same code, so it shouldn't be too =
difficult.

Trevor


-----Original Message-----
From: j=C3=BCrgen h=C3=B6ller [werk3AT] =
[mailto:jue...@we...]
Sent: September 28, 2003 6:33 AM
To: Trevor Cook; Spring Developers
Subject: Re: [Springframework-developer] Multipart File Handling


Hi Trevor,
=20
A MultipartResolver interface with implementations for Commons =
FileUpload and COS is fine with me - it just hadn't high priority since =
I proposed it half a year ago. As I still have a pretty clear picture of =
the issues, I'll be happy to review your code once you've checked it in. =
As this should be pretty straightforward, let's try to include this =
already in 1.0 M2 - at least with a Commons FileUpload implementation.
=20
BTW, in contrast to COS, Commons FileUpload doesn't provide a Servlet =
2.3 filter anyway. This means that there would be some infrastructure =
code to write for that use case too, even when using standard filters. A =
simple but convenient Spring solution would definitely be a good thing.
=20
Juergen
=20
=20
=20

	-----Ursprngliche Nachricht-----=20
	Von: Trevor Cook [mailto:pr...@se...]=20
	Gesendet: Sa 27.09.2003 19:35=20
	An: Spring Developers=20
	Cc:=20
	Betreff: [[W3-SPAM]] - [Springframework-developer] Multipart File =
Handling - Email found in subject
=09
=09

	First some history:
	http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279
	http://sourceforge.net/mailarchive/message.php?msg_id=3D5175276
	=
http://sourceforge.net/mailarchive/forum.php?thread_id=3D3125561&forum_id=
=3D3028
	7
	http://sourceforge.net/mailarchive/message.php?msg_id=3D6062288
=09
	To address a few things Juergen mentioned previously.
=09
	>> a less intrusive way would be to wrap the HttpServletRequest via a =
filter
	I personally don't like the filter approach, at least for the =
framework.  It
	requires additional setup for the user (in the web.xml file) and might =
be
	less understandable since our normal strategy so far has been with =
resolvers
	inside the servlet.
=09
	>>we would need to find concrete requirements for this
	We have numerous uses for file upload handling.  We have a public photo
	contest where users can upload fotos.  We have special access for =
suppliers
	to upload product files (csv) which we then add in to our ordering =
system.
	Finally, we have a web administration interface which allows our client =
to
	upload files to the website so they can be downloaded.  I think that
	including this support (multipart handling) is a no-brainer.
=09
	Basically, I have used COS exclusively in our projects, but I don't =
think
	that's easy for Spring to use (due to the licensing).  I would simply =
code
	this according to Spring norms using an interface and a default version
	using Commons FileUpload.  Later, if somebody wants to create a cos =
version
	we can (but to be honest, if we have a working, integrated solution I'm =
not
	sure that is necessary - at least not in the Spring framework).  =
Basically,
	provide hooks and a default implementation, and allow users to adopt as
	necessary.
=09
	In our project we had modified the AbstractController and put the code =
into
	it to handle the multipart processing, returning a wrapped
	HttpServletRequest through the handlers.  This is very similiar to =
Juergen's
	outline =
(http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279).
=09
	Since we are migrating to the current Spring codebase, I need to move =
our
	multipart handling code.  The main question is whether we keep it
	internally, or place it into Spring.  I propose modifying
	org.springframework.web.servlet.DispatcherServlet to have a
	"MultipartResolver".  In the DispatcherServlet, the resolver would be =
called
	to wrap the request in doService immediately before getHandler(request) =
-
	currently line 351, and then called to do any cleanup immediately =
before
	exiting the doService method.
=09
	I have about 2/3 of the code already written, and I will be writing the =
rest
	between now and Monday.  Does this strategy sound appropriate for =
Spring
	(meaning should I commit it to the Spring codebase) when it's finished?
=09
	Trevor D. Cook
	Interprise Software
=09
=09
=09
	-------------------------------------------------------
	This sf.net email is sponsored by:ThinkGeek
	Welcome to geek heaven.
	http://thinkgeek.com/sf
	_______________________________________________
	Springframework-developer mailing list
	Spr...@li...
	https://lists.sourceforge.net/lists/listinfo/springframework-developer
=09

RE: [Springframework-developer] Multipart File Handling

[Trevor C. <pr...@se...>]

>>Furthermore I think it's pretty cool if the fileupload could be fixed =
before the 1.0 release! Good thing!
I'm working under "business deadlines", so I actually need to have this =
stuff done by Wednesday night, so it will definately be in by 1.0 :)

Trevor

RE: [Springframework-developer] DispatcherServlet - no mapping found

[Trevor C. <pr...@se...>]

I like that idea, but what name do we use for the log?  A simple
"PageNotFound" name, or a packaged name like
"org.springframework.web.servlet.PageNotFound".  I favor the latter since
you could also just have all the web stuff in a single log.

The other question is whether we create a marker interface to show that
we've used this name for logging?

Trevor


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: September 28, 2003 4:02 AM
To: Trevor Cook; Spring Developers
Subject: Re: [Springframework-developer] DispatcherServlet - no mapping
found


Trevor,

On thinking it over further, making this an error was clearly a mistake.
Page not founds probably deserve their own logging category, so they could
be output completely separately from other messages.

Thoughts on this?

Regards,
Rod

----- Original Message -----
From: "Rod Johnson" <rod...@in...>
To: "Trevor Cook" <pr...@se...>; "Spring Developers"
<spr...@li...>
Sent: Saturday, September 27, 2003 10:18 PM
Subject: Re: [Springframework-developer] DispatcherServlet - no mapping
found


> Trevor,
>
> Sounds reasonable. I'm happy for you to change it.
>
> Regards,
> Rod
>
> ----- Original Message -----
> From: "Trevor Cook" <pr...@se...>
> To: "Spring Developers" <spr...@li...>
> Sent: Saturday, September 27, 2003 7:21 PM
> Subject: [Springframework-developer] DispatcherServlet - no mapping found
>
>
> > I have a bit of a problem with the DispatcherServlet's doService method,
> > specifically:
> >
> > if (mappedHandler == null || mappedHandler.getHandler() == null) {
> > // if we didn't find a handler
> > logger.error("No mapping for [" + WebUtils.getRequestUri(request) + "]
in
> > DispatcherServlet with name '" + getServletName() + "'");
> > response.sendError(HttpServletResponse.SC_NOT_FOUND);
> > return;
> > }
> >
> > I think the 404 is fine (I noticed the previous thread for multiaction
on
> > this - see
> http://sourceforge.net/mailarchive/message.php?msg_id=5986871).
> > My problem is "logger.error".  I have log4j send me anything above info
> for
> > my code, and anything error/fatal for Spring.  Because of this, I am
> > currently getting dozens of emails a day from spiders, spelling errors,
> and
> > 1 site that refuses to change a bad link on their page.   I considered
> just
> > changing my logging to only report fatal errors from Spring, but Spring
> > doesn't have any, and other errors it reports are important (like
> > transaction and configuration problems).  I'd like to change this from
> error
> > to warn.  "warn" is defined as:
> >
> > <quote>other runtime situations that are undesirable or unexpected, but
> not
> > necessarily "wrong".</quote> see
> > http://jakarta.apache.org/commons/logging/userguide.html
> >
> > I think that a 404 is not a desirable thing, but is fairly normal for a
> > webapp, so falls under the "not wrong" category.
> >
> > Let me know if there is general support for lowering the logging level
of
> > this message, or if I'm totally out to lunch.
> >
> > Trevor D. Cook
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

RE: [Springframework-developer] Multipart File Handling

[Alef A. \(JTeam\) <al...@jt...>]

The conversion interface might indeed not be the perfect solution. A =
byte[] check is fine and fits the needs perfectly!

Alef


-----Oorspronkelijk bericht-----
Van: j=C3=BCrgen h=C3=B6ller [werk3AT] =
[mailto:jue...@we...]=20
Verzonden: Sunday, September 28, 2003 4:20 PM
Aan: al...@jt...; Trevor Cook; Spring Developers
Onderwerp: Re: [Springframework-developer] Multipart File Handling


Alef,
=20
I'm not keen on introducing yet another converter interface, especially =
as there's hardly any variation possible in terms of file upload =
handling. I agree though that having MultipartFile in the object model =
isn't desirable.
=20
What about writing the automatic check in ServletRequestDataBinder so =
that it assumes a byte[] for the uploaded file? I can't think of any =
other generic type suitable for uploaded files. java.io.File is no =
candidate as we would need to determine a path to save the file to. I =
consider such persisting the responsibility of the application code =
itself, especially as the uploaded stuff will often be stored to a =
relational database.
=20
For anything else than byte[] as property type in a command object, even =
MultipartFile if desired, one can always override onBindAndValidate and =
perform manual binding. Would that be powerful enough for your use =
cases?
=20
Juergen
=20
=20

	-----Urspr=C3=BCngliche Nachricht-----=20
	Von: Alef Arendsen (JTeam) [mailto:al...@jt...]=20
	Gesendet: So 28.09.2003 15:31=20
	An: j=C3=BCrgen h=C3=B6ller [werk3AT]; 'Trevor Cook'; 'Spring =
Developers'=20
	Cc:=20
	Betreff: RE: [Springframework-developer] Multipart File Handling
=09
=09

	In one of my previous mails I mentioned doing something like that. It =
involved base64 encoding the byte[] to a String, after which the =
propertyeditor picked it up, decoded it again into a byte[] and set it =
on the object! Arghhh.... (as in wow that's ugly ;-).
=09
	I did this, because I rely completely on the mvc framework and 1) did =
not want to put in some MultiPart object in my object model, I just =
wanted a byte[] and 2) just didn't want to make compromises simply =
because of propertyeditors being only capable of handling Strings. Ok, =
the solution is nasty and definitely not up for adding, but I really =
think it should worked in such way that things stay consistent while on =
the other hand, not forcing a user at all to modify stuff in it's =
datamodel... May sound a bit harsh, sorry for that ;-)
=09
	Would it be possible to define a simple Spring-proprietary conversion =
interface/class which users can implement themselves capable of =
transforming multpartfile object (or whatever other type) to objects =
defined in a user's datamodel. Something like the following.
=09
	class FileUploadConvertor {
	        public Object convert(MultiPartFile);
	}
=09
	Just some thoughts...
=09
	Alef
=09
=09
	-----Oorspronkelijk bericht-----
	Van: spr...@li... =
[mailto:spr...@li...] Namens =
j=C3=BCrgen h=C3=B6ller [werk3AT]
	Verzonden: Sunday, September 28, 2003 2:31 PM
	Aan: al...@jt...; Trevor Cook; Spring Developers
	Onderwerp: Re: [Springframework-developer] Multipart File Handling
=09
=09
	Hi Alef,
=09
	A PropertyEditor will always start with a String and convert it to some =
other type, in the web case applied to ServletRequest's getParameter =
values. Here we got MultipartFile instances, retrievable via =
MultipartServletRequest's getFile(String name) method: no Strings in the =
first place, thus the PropertyEditor mechanism is not applicable.
=09
	We could possibly add a special check to ServletRequestDataBinder, =
binding MultipartFile instances to respective command bean fields of the =
same type in the case of a multipart request. That would work with any =
MultipartResolver implementation, as it could use the same API as manual =
file upload handling code that casts to MultipartServletRequest.
=09
	Definitely a feature worth considering!
=09
	Juergen
=09
=09
=09
	        -----Urspr=C3=BCngliche Nachricht-----
	        Von: Alef Arendsen (JTeam) [mailto:al...@jt...]
	        Gesendet: So 28.09.2003 14:04
	        An: j=C3=BCrgen h=C3=B6ller [werk3AT]; 'Trevor Cook'; 'Spring =
Developers'
	        Cc:
	        Betreff: RE: [Springframework-developer] Multipart File =
Handling
	      =20
	      =20
=09
	        Will there be a way - using this solution - to bind the file =
using a propertyeditor (or something else maybe), just as any other =
command object is filled with parameters from the request. For =
consistency, I think that's pretty important to be consistent.
	      =20
	        Furthermore I think it's pretty cool if the fileupload could be =
fixed before the 1.0 release! Good thing!
	      =20
	        Alef
	      =20
	      =20
	        -----Oorspronkelijk bericht-----
	        Van: spr...@li... =
[mailto:spr...@li...] Namens =
j=C3=BCrgen h=C3=B6ller [werk3AT]
	        Verzonden: Sunday, September 28, 2003 12:33 PM
	        Aan: Trevor Cook; Spring Developers
	        Onderwerp: Re: [Springframework-developer] Multipart File =
Handling
	      =20
	      =20
	        Hi Trevor,
	      =20
	        A MultipartResolver interface with implementations for Commons =
FileUpload and COS is fine with me - it just hadn't high priority since =
I proposed it half a year ago. As I still have a pretty clear picture of =
the issues, I'll be happy to review your code once you've checked it in. =
As this should be pretty straightforward, let's try to include this =
already in 1.0 M2 - at least with a Commons FileUpload implementation.
	      =20
	        BTW, in contrast to COS, Commons FileUpload doesn't provide a =
Servlet 2.3 filter anyway. This means that there would be some =
infrastructure code to write for that use case too, even when using =
standard filters. A simple but convenient Spring solution would =
definitely be a good thing.
	      =20
	        Juergen
	      =20
	      =20
	      =20
	      =20
	                -----Urspr=C3=BCngliche Nachricht-----
	                Von: Trevor Cook [mailto:pr...@se...]
	                Gesendet: Sa 27.09.2003 19:35
	                An: Spring Developers
	                Cc:
	                Betreff: [[W3-SPAM]] - [Springframework-developer] =
Multipart File Handling - Email found in subject
	             =20
	             =20
	      =20
	                First some history:
	                =
http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279
	                =
http://sourceforge.net/mailarchive/message.php?msg_id=3D5175276
	                =
http://sourceforge.net/mailarchive/forum.php?thread_id=3D3125561&forum_id=
=3D3028
	                7
	                =
http://sourceforge.net/mailarchive/message.php?msg_id=3D6062288
	             =20
	                To address a few things Juergen mentioned previously.
	             =20
	                >> a less intrusive way would be to wrap the =
HttpServletRequest via a filter
	                I personally don't like the filter approach, at least =
for the framework.  It
	                requires additional setup for the user (in the web.xml =
file) and might be
	                less understandable since our normal strategy so far =
has been with resolvers
	                inside the servlet.
	             =20
	                >>we would need to find concrete requirements for this
	                We have numerous uses for file upload handling.  We =
have a public photo
	                contest where users can upload fotos.  We have special =
access for suppliers
	                to upload product files (csv) which we then add in to =
our ordering system.
	                Finally, we have a web administration interface which =
allows our client to
	                upload files to the website so they can be downloaded.  =
I think that
	                including this support (multipart handling) is a =
no-brainer.
	             =20
	                Basically, I have used COS exclusively in our projects, =
but I don't think
	                that's easy for Spring to use (due to the licensing).  =
I would simply code
	                this according to Spring norms using an interface and a =
default version
	                using Commons FileUpload.  Later, if somebody wants to =
create a cos version
	                we can (but to be honest, if we have a working, =
integrated solution I'm not
	                sure that is necessary - at least not in the Spring =
framework).  Basically,
	                provide hooks and a default implementation, and allow =
users to adopt as
	                necessary.
	             =20
	                In our project we had modified the AbstractController =
and put the code into
	                it to handle the multipart processing, returning a =
wrapped
	                HttpServletRequest through the handlers.  This is very =
similiar to Juergen's
	                outline =
(http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279).
	             =20
	                Since we are migrating to the current Spring codebase, =
I need to move our
	                multipart handling code.  The main question is whether =
we keep it
	                internally, or place it into Spring.  I propose =
modifying
	                org.springframework.web.servlet.DispatcherServlet to =
have a
	                "MultipartResolver".  In the DispatcherServlet, the =
resolver would be called
	                to wrap the request in doService immediately before =
getHandler(request) -
	                currently line 351, and then called to do any cleanup =
immediately before
	                exiting the doService method.
	             =20
	                I have about 2/3 of the code already written, and I =
will be writing the rest
	                between now and Monday.  Does this strategy sound =
appropriate for Spring
	                (meaning should I commit it to the Spring codebase) =
when it's finished?
	             =20
	                Trevor D. Cook
	                Interprise Software
	             =20
	             =20
	             =20
	                -------------------------------------------------------
	                This sf.net email is sponsored by:ThinkGeek
	                Welcome to geek heaven.
	                http://thinkgeek.com/sf
	                _______________________________________________
	                Springframework-developer mailing list
	                Spr...@li...
	                =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
	             =20
	      =20
	        N=18 Xu)=19Y g =17  HzGJ jg=EE=A2=B9z=ED=BD=89=ED=B7=99x=CB=A6 =
G =CB=B2q z m?X (=1E~zw X b=CB=9D?  jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97
	      =20
	      =20
=09
	N=18 =E9=9A=8AX'u=DE=BC)=19 Y\g=E9=A2=AD =17 =7F b=D8=9EH=1EzG(=1FJ  =
jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97x%R=CB=A6 (G^=EC=AE=BDh  lq  zm=D8=B6?X =
(=1E~zw X b=CB=9D?  jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97
=09
=09

Re: [Springframework-developer] Multipart File Handling

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

QWxlZiwNCiANCkknbSBub3Qga2VlbiBvbiBpbnRyb2R1Y2luZyB5ZXQgYW5vdGhlciBjb252ZXJ0
ZXIgaW50ZXJmYWNlLCBlc3BlY2lhbGx5IGFzIHRoZXJlJ3MgaGFyZGx5IGFueSB2YXJpYXRpb24g
cG9zc2libGUgaW4gdGVybXMgb2YgZmlsZSB1cGxvYWQgaGFuZGxpbmcuIEkgYWdyZWUgdGhvdWdo
IHRoYXQgaGF2aW5nIE11bHRpcGFydEZpbGUgaW4gdGhlIG9iamVjdCBtb2RlbCBpc24ndCBkZXNp
cmFibGUuDQogDQpXaGF0IGFib3V0IHdyaXRpbmcgdGhlIGF1dG9tYXRpYyBjaGVjayBpbiBTZXJ2
bGV0UmVxdWVzdERhdGFCaW5kZXIgc28gdGhhdCBpdCBhc3N1bWVzIGEgYnl0ZVtdIGZvciB0aGUg
dXBsb2FkZWQgZmlsZT8gSSBjYW4ndCB0aGluayBvZiBhbnkgb3RoZXIgZ2VuZXJpYyB0eXBlIHN1
aXRhYmxlIGZvciB1cGxvYWRlZCBmaWxlcy4gamF2YS5pby5GaWxlIGlzIG5vIGNhbmRpZGF0ZSBh
cyB3ZSB3b3VsZCBuZWVkIHRvIGRldGVybWluZSBhIHBhdGggdG8gc2F2ZSB0aGUgZmlsZSB0by4g
SSBjb25zaWRlciBzdWNoIHBlcnNpc3RpbmcgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBhcHBs
aWNhdGlvbiBjb2RlIGl0c2VsZiwgZXNwZWNpYWxseSBhcyB0aGUgdXBsb2FkZWQgc3R1ZmYgd2ls
bCBvZnRlbiBiZSBzdG9yZWQgdG8gYSByZWxhdGlvbmFsIGRhdGFiYXNlLg0KIA0KRm9yIGFueXRo
aW5nIGVsc2UgdGhhbiBieXRlW10gYXMgcHJvcGVydHkgdHlwZSBpbiBhIGNvbW1hbmQgb2JqZWN0
LCBldmVuIE11bHRpcGFydEZpbGUgaWYgZGVzaXJlZCwgb25lIGNhbiBhbHdheXMgb3ZlcnJpZGUg
b25CaW5kQW5kVmFsaWRhdGUgYW5kIHBlcmZvcm0gbWFudWFsIGJpbmRpbmcuIFdvdWxkIHRoYXQg
YmUgcG93ZXJmdWwgZW5vdWdoIGZvciB5b3VyIHVzZSBjYXNlcz8NCiANCkp1ZXJnZW4NCiANCiAN
Cg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBBbGVmIEFyZW5k
c2VuIChKVGVhbSkgW21haWx0bzphbGVmQGp0ZWFtLm5sXSANCglHZXNlbmRldDogU28gMjguMDku
MjAwMyAxNTozMSANCglBbjogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXTsgJ1RyZXZvciBDb29r
JzsgJ1NwcmluZyBEZXZlbG9wZXJzJyANCglDYzogDQoJQmV0cmVmZjogUkU6IFtTcHJpbmdmcmFt
ZXdvcmstZGV2ZWxvcGVyXSBNdWx0aXBhcnQgRmlsZSBIYW5kbGluZw0KCQ0KCQ0KDQoJSW4gb25l
IG9mIG15IHByZXZpb3VzIG1haWxzIEkgbWVudGlvbmVkIGRvaW5nIHNvbWV0aGluZyBsaWtlIHRo
YXQuIEl0IGludm9sdmVkIGJhc2U2NCBlbmNvZGluZyB0aGUgYnl0ZVtdIHRvIGEgU3RyaW5nLCBh
ZnRlciB3aGljaCB0aGUgcHJvcGVydHllZGl0b3IgcGlja2VkIGl0IHVwLCBkZWNvZGVkIGl0IGFn
YWluIGludG8gYSBieXRlW10gYW5kIHNldCBpdCBvbiB0aGUgb2JqZWN0ISBBcmdoaGguLi4uIChh
cyBpbiB3b3cgdGhhdCdzIHVnbHkgOy0pLg0KCQ0KCUkgZGlkIHRoaXMsIGJlY2F1c2UgSSByZWx5
IGNvbXBsZXRlbHkgb24gdGhlIG12YyBmcmFtZXdvcmsgYW5kIDEpIGRpZCBub3Qgd2FudCB0byBw
dXQgaW4gc29tZSBNdWx0aVBhcnQgb2JqZWN0IGluIG15IG9iamVjdCBtb2RlbCwgSSBqdXN0IHdh
bnRlZCBhIGJ5dGVbXSBhbmQgMikganVzdCBkaWRuJ3Qgd2FudCB0byBtYWtlIGNvbXByb21pc2Vz
IHNpbXBseSBiZWNhdXNlIG9mIHByb3BlcnR5ZWRpdG9ycyBiZWluZyBvbmx5IGNhcGFibGUgb2Yg
aGFuZGxpbmcgU3RyaW5ncy4gT2ssIHRoZSBzb2x1dGlvbiBpcyBuYXN0eSBhbmQgZGVmaW5pdGVs
eSBub3QgdXAgZm9yIGFkZGluZywgYnV0IEkgcmVhbGx5IHRoaW5rIGl0IHNob3VsZCB3b3JrZWQg
aW4gc3VjaCB3YXkgdGhhdCB0aGluZ3Mgc3RheSBjb25zaXN0ZW50IHdoaWxlIG9uIHRoZSBvdGhl
ciBoYW5kLCBub3QgZm9yY2luZyBhIHVzZXIgYXQgYWxsIHRvIG1vZGlmeSBzdHVmZiBpbiBpdCdz
IGRhdGFtb2RlbC4uLiBNYXkgc291bmQgYSBiaXQgaGFyc2gsIHNvcnJ5IGZvciB0aGF0IDstKQ0K
CQ0KCVdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGRlZmluZSBhIHNpbXBsZSBTcHJpbmctcHJvcHJp
ZXRhcnkgY29udmVyc2lvbiBpbnRlcmZhY2UvY2xhc3Mgd2hpY2ggdXNlcnMgY2FuIGltcGxlbWVu
dCB0aGVtc2VsdmVzIGNhcGFibGUgb2YgdHJhbnNmb3JtaW5nIG11bHRwYXJ0ZmlsZSBvYmplY3Qg
KG9yIHdoYXRldmVyIG90aGVyIHR5cGUpIHRvIG9iamVjdHMgZGVmaW5lZCBpbiBhIHVzZXIncyBk
YXRhbW9kZWwuIFNvbWV0aGluZyBsaWtlIHRoZSBmb2xsb3dpbmcuDQoJDQoJY2xhc3MgRmlsZVVw
bG9hZENvbnZlcnRvciB7DQoJICAgICAgICBwdWJsaWMgT2JqZWN0IGNvbnZlcnQoTXVsdGlQYXJ0
RmlsZSk7DQoJfQ0KCQ0KCUp1c3Qgc29tZSB0aG91Z2h0cy4uLg0KCQ0KCUFsZWYNCgkNCgkNCgkt
LS0tLU9vcnNwcm9ua2VsaWprIGJlcmljaHQtLS0tLQ0KCVZhbjogc3ByaW5nZnJhbWV3b3JrLWRl
dmVsb3Blci1hZG1pbkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgW21haWx0bzpzcHJpbmdmcmFtZXdv
cmstZGV2ZWxvcGVyLWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldF0gTmFtZW5zIGrDvHJnZW4g
aMO2bGxlciBbd2VyazNBVF0NCglWZXJ6b25kZW46IFN1bmRheSwgU2VwdGVtYmVyIDI4LCAyMDAz
IDI6MzEgUE0NCglBYW46IGFsZWZAanRlYW0ubmw7IFRyZXZvciBDb29rOyBTcHJpbmcgRGV2ZWxv
cGVycw0KCU9uZGVyd2VycDogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBNdWx0aXBh
cnQgRmlsZSBIYW5kbGluZw0KCQ0KCQ0KCUhpIEFsZWYsDQoJDQoJQSBQcm9wZXJ0eUVkaXRvciB3
aWxsIGFsd2F5cyBzdGFydCB3aXRoIGEgU3RyaW5nIGFuZCBjb252ZXJ0IGl0IHRvIHNvbWUgb3Ro
ZXIgdHlwZSwgaW4gdGhlIHdlYiBjYXNlIGFwcGxpZWQgdG8gU2VydmxldFJlcXVlc3QncyBnZXRQ
YXJhbWV0ZXIgdmFsdWVzLiBIZXJlIHdlIGdvdCBNdWx0aXBhcnRGaWxlIGluc3RhbmNlcywgcmV0
cmlldmFibGUgdmlhIE11bHRpcGFydFNlcnZsZXRSZXF1ZXN0J3MgZ2V0RmlsZShTdHJpbmcgbmFt
ZSkgbWV0aG9kOiBubyBTdHJpbmdzIGluIHRoZSBmaXJzdCBwbGFjZSwgdGh1cyB0aGUgUHJvcGVy
dHlFZGl0b3IgbWVjaGFuaXNtIGlzIG5vdCBhcHBsaWNhYmxlLg0KCQ0KCVdlIGNvdWxkIHBvc3Np
Ymx5IGFkZCBhIHNwZWNpYWwgY2hlY2sgdG8gU2VydmxldFJlcXVlc3REYXRhQmluZGVyLCBiaW5k
aW5nIE11bHRpcGFydEZpbGUgaW5zdGFuY2VzIHRvIHJlc3BlY3RpdmUgY29tbWFuZCBiZWFuIGZp
ZWxkcyBvZiB0aGUgc2FtZSB0eXBlIGluIHRoZSBjYXNlIG9mIGEgbXVsdGlwYXJ0IHJlcXVlc3Qu
IFRoYXQgd291bGQgd29yayB3aXRoIGFueSBNdWx0aXBhcnRSZXNvbHZlciBpbXBsZW1lbnRhdGlv
biwgYXMgaXQgY291bGQgdXNlIHRoZSBzYW1lIEFQSSBhcyBtYW51YWwgZmlsZSB1cGxvYWQgaGFu
ZGxpbmcgY29kZSB0aGF0IGNhc3RzIHRvIE11bHRpcGFydFNlcnZsZXRSZXF1ZXN0Lg0KCQ0KCURl
ZmluaXRlbHkgYSBmZWF0dXJlIHdvcnRoIGNvbnNpZGVyaW5nIQ0KCQ0KCUp1ZXJnZW4NCgkNCgkN
CgkNCgkgICAgICAgIC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCgkgICAgICAg
IFZvbjogQWxlZiBBcmVuZHNlbiAoSlRlYW0pIFttYWlsdG86YWxlZkBqdGVhbS5ubF0NCgkgICAg
ICAgIEdlc2VuZGV0OiBTbyAyOC4wOS4yMDAzIDE0OjA0DQoJICAgICAgICBBbjogasO8cmdlbiBo
w7ZsbGVyIFt3ZXJrM0FUXTsgJ1RyZXZvciBDb29rJzsgJ1NwcmluZyBEZXZlbG9wZXJzJw0KCSAg
ICAgICAgQ2M6DQoJICAgICAgICBCZXRyZWZmOiBSRTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9w
ZXJdIE11bHRpcGFydCBGaWxlIEhhbmRsaW5nDQoJICAgICAgIA0KCSAgICAgICANCgkNCgkgICAg
ICAgIFdpbGwgdGhlcmUgYmUgYSB3YXkgLSB1c2luZyB0aGlzIHNvbHV0aW9uIC0gdG8gYmluZCB0
aGUgZmlsZSB1c2luZyBhIHByb3BlcnR5ZWRpdG9yIChvciBzb21ldGhpbmcgZWxzZSBtYXliZSks
IGp1c3QgYXMgYW55IG90aGVyIGNvbW1hbmQgb2JqZWN0IGlzIGZpbGxlZCB3aXRoIHBhcmFtZXRl
cnMgZnJvbSB0aGUgcmVxdWVzdC4gRm9yIGNvbnNpc3RlbmN5LCBJIHRoaW5rIHRoYXQncyBwcmV0
dHkgaW1wb3J0YW50IHRvIGJlIGNvbnNpc3RlbnQuDQoJICAgICAgIA0KCSAgICAgICAgRnVydGhl
cm1vcmUgSSB0aGluayBpdCdzIHByZXR0eSBjb29sIGlmIHRoZSBmaWxldXBsb2FkIGNvdWxkIGJl
IGZpeGVkIGJlZm9yZSB0aGUgMS4wIHJlbGVhc2UhIEdvb2QgdGhpbmchDQoJICAgICAgIA0KCSAg
ICAgICAgQWxlZg0KCSAgICAgICANCgkgICAgICAgDQoJICAgICAgICAtLS0tLU9vcnNwcm9ua2Vs
aWprIGJlcmljaHQtLS0tLQ0KCSAgICAgICAgVmFuOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVy
LWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCBbbWFpbHRvOnNwcmluZ2ZyYW1ld29yay1kZXZl
bG9wZXItYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0XSBOYW1lbnMgasO8cmdlbiBow7ZsbGVy
IFt3ZXJrM0FUXQ0KCSAgICAgICAgVmVyem9uZGVuOiBTdW5kYXksIFNlcHRlbWJlciAyOCwgMjAw
MyAxMjozMyBQTQ0KCSAgICAgICAgQWFuOiBUcmV2b3IgQ29vazsgU3ByaW5nIERldmVsb3BlcnMN
CgkgICAgICAgIE9uZGVyd2VycDogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBNdWx0
aXBhcnQgRmlsZSBIYW5kbGluZw0KCSAgICAgICANCgkgICAgICAgDQoJICAgICAgICBIaSBUcmV2
b3IsDQoJICAgICAgIA0KCSAgICAgICAgQSBNdWx0aXBhcnRSZXNvbHZlciBpbnRlcmZhY2Ugd2l0
aCBpbXBsZW1lbnRhdGlvbnMgZm9yIENvbW1vbnMgRmlsZVVwbG9hZCBhbmQgQ09TIGlzIGZpbmUg
d2l0aCBtZSAtIGl0IGp1c3QgaGFkbid0IGhpZ2ggcHJpb3JpdHkgc2luY2UgSSBwcm9wb3NlZCBp
dCBoYWxmIGEgeWVhciBhZ28uIEFzIEkgc3RpbGwgaGF2ZSBhIHByZXR0eSBjbGVhciBwaWN0dXJl
IG9mIHRoZSBpc3N1ZXMsIEknbGwgYmUgaGFwcHkgdG8gcmV2aWV3IHlvdXIgY29kZSBvbmNlIHlv
dSd2ZSBjaGVja2VkIGl0IGluLiBBcyB0aGlzIHNob3VsZCBiZSBwcmV0dHkgc3RyYWlnaHRmb3J3
YXJkLCBsZXQncyB0cnkgdG8gaW5jbHVkZSB0aGlzIGFscmVhZHkgaW4gMS4wIE0yIC0gYXQgbGVh
c3Qgd2l0aCBhIENvbW1vbnMgRmlsZVVwbG9hZCBpbXBsZW1lbnRhdGlvbi4NCgkgICAgICAgDQoJ
ICAgICAgICBCVFcsIGluIGNvbnRyYXN0IHRvIENPUywgQ29tbW9ucyBGaWxlVXBsb2FkIGRvZXNu
J3QgcHJvdmlkZSBhIFNlcnZsZXQgMi4zIGZpbHRlciBhbnl3YXkuIFRoaXMgbWVhbnMgdGhhdCB0
aGVyZSB3b3VsZCBiZSBzb21lIGluZnJhc3RydWN0dXJlIGNvZGUgdG8gd3JpdGUgZm9yIHRoYXQg
dXNlIGNhc2UgdG9vLCBldmVuIHdoZW4gdXNpbmcgc3RhbmRhcmQgZmlsdGVycy4gQSBzaW1wbGUg
YnV0IGNvbnZlbmllbnQgU3ByaW5nIHNvbHV0aW9uIHdvdWxkIGRlZmluaXRlbHkgYmUgYSBnb29k
IHRoaW5nLg0KCSAgICAgICANCgkgICAgICAgIEp1ZXJnZW4NCgkgICAgICAgDQoJICAgICAgIA0K
CSAgICAgICANCgkgICAgICAgDQoJICAgICAgICAgICAgICAgIC0tLS0tVXJzcHLDvG5nbGljaGUg
TmFjaHJpY2h0LS0tLS0NCgkgICAgICAgICAgICAgICAgVm9uOiBUcmV2b3IgQ29vayBbbWFpbHRv
OnByaXNlMDNAc2VudGV4Lm5ldF0NCgkgICAgICAgICAgICAgICAgR2VzZW5kZXQ6IFNhIDI3LjA5
LjIwMDMgMTk6MzUNCgkgICAgICAgICAgICAgICAgQW46IFNwcmluZyBEZXZlbG9wZXJzDQoJICAg
ICAgICAgICAgICAgIENjOg0KCSAgICAgICAgICAgICAgICBCZXRyZWZmOiBbW1czLVNQQU1dXSAt
IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBNdWx0aXBhcnQgRmlsZSBIYW5kbGluZyAtIEVt
YWlsIGZvdW5kIGluIHN1YmplY3QNCgkgICAgICAgICAgICAgIA0KCSAgICAgICAgICAgICAgDQoJ
ICAgICAgIA0KCSAgICAgICAgICAgICAgICBGaXJzdCBzb21lIGhpc3Rvcnk6DQoJICAgICAgICAg
ICAgICAgIGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvbWFpbGFyY2hpdmUvbWVzc2FnZS5waHA/bXNn
X2lkPTM4OTEyNzkNCgkgICAgICAgICAgICAgICAgaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9tYWls
YXJjaGl2ZS9tZXNzYWdlLnBocD9tc2dfaWQ9NTE3NTI3Ng0KCSAgICAgICAgICAgICAgICBodHRw
Oi8vc291cmNlZm9yZ2UubmV0L21haWxhcmNoaXZlL2ZvcnVtLnBocD90aHJlYWRfaWQ9MzEyNTU2
MSZmb3J1bV9pZD0zMDI4DQoJICAgICAgICAgICAgICAgIDcNCgkgICAgICAgICAgICAgICAgaHR0
cDovL3NvdXJjZWZvcmdlLm5ldC9tYWlsYXJjaGl2ZS9tZXNzYWdlLnBocD9tc2dfaWQ9NjA2MjI4
OA0KCSAgICAgICAgICAgICAgDQoJICAgICAgICAgICAgICAgIFRvIGFkZHJlc3MgYSBmZXcgdGhp
bmdzIEp1ZXJnZW4gbWVudGlvbmVkIHByZXZpb3VzbHkuDQoJICAgICAgICAgICAgICANCgkgICAg
ICAgICAgICAgICAgPj4gYSBsZXNzIGludHJ1c2l2ZSB3YXkgd291bGQgYmUgdG8gd3JhcCB0aGUg
SHR0cFNlcnZsZXRSZXF1ZXN0IHZpYSBhIGZpbHRlcg0KCSAgICAgICAgICAgICAgICBJIHBlcnNv
bmFsbHkgZG9uJ3QgbGlrZSB0aGUgZmlsdGVyIGFwcHJvYWNoLCBhdCBsZWFzdCBmb3IgdGhlIGZy
YW1ld29yay4gIEl0DQoJICAgICAgICAgICAgICAgIHJlcXVpcmVzIGFkZGl0aW9uYWwgc2V0dXAg
Zm9yIHRoZSB1c2VyIChpbiB0aGUgd2ViLnhtbCBmaWxlKSBhbmQgbWlnaHQgYmUNCgkgICAgICAg
ICAgICAgICAgbGVzcyB1bmRlcnN0YW5kYWJsZSBzaW5jZSBvdXIgbm9ybWFsIHN0cmF0ZWd5IHNv
IGZhciBoYXMgYmVlbiB3aXRoIHJlc29sdmVycw0KCSAgICAgICAgICAgICAgICBpbnNpZGUgdGhl
IHNlcnZsZXQuDQoJICAgICAgICAgICAgICANCgkgICAgICAgICAgICAgICAgPj53ZSB3b3VsZCBu
ZWVkIHRvIGZpbmQgY29uY3JldGUgcmVxdWlyZW1lbnRzIGZvciB0aGlzDQoJICAgICAgICAgICAg
ICAgIFdlIGhhdmUgbnVtZXJvdXMgdXNlcyBmb3IgZmlsZSB1cGxvYWQgaGFuZGxpbmcuICBXZSBo
YXZlIGEgcHVibGljIHBob3RvDQoJICAgICAgICAgICAgICAgIGNvbnRlc3Qgd2hlcmUgdXNlcnMg
Y2FuIHVwbG9hZCBmb3Rvcy4gIFdlIGhhdmUgc3BlY2lhbCBhY2Nlc3MgZm9yIHN1cHBsaWVycw0K
CSAgICAgICAgICAgICAgICB0byB1cGxvYWQgcHJvZHVjdCBmaWxlcyAoY3N2KSB3aGljaCB3ZSB0
aGVuIGFkZCBpbiB0byBvdXIgb3JkZXJpbmcgc3lzdGVtLg0KCSAgICAgICAgICAgICAgICBGaW5h
bGx5LCB3ZSBoYXZlIGEgd2ViIGFkbWluaXN0cmF0aW9uIGludGVyZmFjZSB3aGljaCBhbGxvd3Mg
b3VyIGNsaWVudCB0bw0KCSAgICAgICAgICAgICAgICB1cGxvYWQgZmlsZXMgdG8gdGhlIHdlYnNp
dGUgc28gdGhleSBjYW4gYmUgZG93bmxvYWRlZC4gIEkgdGhpbmsgdGhhdA0KCSAgICAgICAgICAg
ICAgICBpbmNsdWRpbmcgdGhpcyBzdXBwb3J0IChtdWx0aXBhcnQgaGFuZGxpbmcpIGlzIGEgbm8t
YnJhaW5lci4NCgkgICAgICAgICAgICAgIA0KCSAgICAgICAgICAgICAgICBCYXNpY2FsbHksIEkg
aGF2ZSB1c2VkIENPUyBleGNsdXNpdmVseSBpbiBvdXIgcHJvamVjdHMsIGJ1dCBJIGRvbid0IHRo
aW5rDQoJICAgICAgICAgICAgICAgIHRoYXQncyBlYXN5IGZvciBTcHJpbmcgdG8gdXNlIChkdWUg
dG8gdGhlIGxpY2Vuc2luZykuICBJIHdvdWxkIHNpbXBseSBjb2RlDQoJICAgICAgICAgICAgICAg
IHRoaXMgYWNjb3JkaW5nIHRvIFNwcmluZyBub3JtcyB1c2luZyBhbiBpbnRlcmZhY2UgYW5kIGEg
ZGVmYXVsdCB2ZXJzaW9uDQoJICAgICAgICAgICAgICAgIHVzaW5nIENvbW1vbnMgRmlsZVVwbG9h
ZC4gIExhdGVyLCBpZiBzb21lYm9keSB3YW50cyB0byBjcmVhdGUgYSBjb3MgdmVyc2lvbg0KCSAg
ICAgICAgICAgICAgICB3ZSBjYW4gKGJ1dCB0byBiZSBob25lc3QsIGlmIHdlIGhhdmUgYSB3b3Jr
aW5nLCBpbnRlZ3JhdGVkIHNvbHV0aW9uIEknbSBub3QNCgkgICAgICAgICAgICAgICAgc3VyZSB0
aGF0IGlzIG5lY2Vzc2FyeSAtIGF0IGxlYXN0IG5vdCBpbiB0aGUgU3ByaW5nIGZyYW1ld29yayku
ICBCYXNpY2FsbHksDQoJICAgICAgICAgICAgICAgIHByb3ZpZGUgaG9va3MgYW5kIGEgZGVmYXVs
dCBpbXBsZW1lbnRhdGlvbiwgYW5kIGFsbG93IHVzZXJzIHRvIGFkb3B0IGFzDQoJICAgICAgICAg
ICAgICAgIG5lY2Vzc2FyeS4NCgkgICAgICAgICAgICAgIA0KCSAgICAgICAgICAgICAgICBJbiBv
dXIgcHJvamVjdCB3ZSBoYWQgbW9kaWZpZWQgdGhlIEFic3RyYWN0Q29udHJvbGxlciBhbmQgcHV0
IHRoZSBjb2RlIGludG8NCgkgICAgICAgICAgICAgICAgaXQgdG8gaGFuZGxlIHRoZSBtdWx0aXBh
cnQgcHJvY2Vzc2luZywgcmV0dXJuaW5nIGEgd3JhcHBlZA0KCSAgICAgICAgICAgICAgICBIdHRw
U2VydmxldFJlcXVlc3QgdGhyb3VnaCB0aGUgaGFuZGxlcnMuICBUaGlzIGlzIHZlcnkgc2ltaWxp
YXIgdG8gSnVlcmdlbidzDQoJICAgICAgICAgICAgICAgIG91dGxpbmUgKGh0dHA6Ly9zb3VyY2Vm
b3JnZS5uZXQvbWFpbGFyY2hpdmUvbWVzc2FnZS5waHA/bXNnX2lkPTM4OTEyNzkpLg0KCSAgICAg
ICAgICAgICAgDQoJICAgICAgICAgICAgICAgIFNpbmNlIHdlIGFyZSBtaWdyYXRpbmcgdG8gdGhl
IGN1cnJlbnQgU3ByaW5nIGNvZGViYXNlLCBJIG5lZWQgdG8gbW92ZSBvdXINCgkgICAgICAgICAg
ICAgICAgbXVsdGlwYXJ0IGhhbmRsaW5nIGNvZGUuICBUaGUgbWFpbiBxdWVzdGlvbiBpcyB3aGV0
aGVyIHdlIGtlZXAgaXQNCgkgICAgICAgICAgICAgICAgaW50ZXJuYWxseSwgb3IgcGxhY2UgaXQg
aW50byBTcHJpbmcuICBJIHByb3Bvc2UgbW9kaWZ5aW5nDQoJICAgICAgICAgICAgICAgIG9yZy5z
cHJpbmdmcmFtZXdvcmsud2ViLnNlcnZsZXQuRGlzcGF0Y2hlclNlcnZsZXQgdG8gaGF2ZSBhDQoJ
ICAgICAgICAgICAgICAgICJNdWx0aXBhcnRSZXNvbHZlciIuICBJbiB0aGUgRGlzcGF0Y2hlclNl
cnZsZXQsIHRoZSByZXNvbHZlciB3b3VsZCBiZSBjYWxsZWQNCgkgICAgICAgICAgICAgICAgdG8g
d3JhcCB0aGUgcmVxdWVzdCBpbiBkb1NlcnZpY2UgaW1tZWRpYXRlbHkgYmVmb3JlIGdldEhhbmRs
ZXIocmVxdWVzdCkgLQ0KCSAgICAgICAgICAgICAgICBjdXJyZW50bHkgbGluZSAzNTEsIGFuZCB0
aGVuIGNhbGxlZCB0byBkbyBhbnkgY2xlYW51cCBpbW1lZGlhdGVseSBiZWZvcmUNCgkgICAgICAg
ICAgICAgICAgZXhpdGluZyB0aGUgZG9TZXJ2aWNlIG1ldGhvZC4NCgkgICAgICAgICAgICAgIA0K
CSAgICAgICAgICAgICAgICBJIGhhdmUgYWJvdXQgMi8zIG9mIHRoZSBjb2RlIGFscmVhZHkgd3Jp
dHRlbiwgYW5kIEkgd2lsbCBiZSB3cml0aW5nIHRoZSByZXN0DQoJICAgICAgICAgICAgICAgIGJl
dHdlZW4gbm93IGFuZCBNb25kYXkuICBEb2VzIHRoaXMgc3RyYXRlZ3kgc291bmQgYXBwcm9wcmlh
dGUgZm9yIFNwcmluZw0KCSAgICAgICAgICAgICAgICAobWVhbmluZyBzaG91bGQgSSBjb21taXQg
aXQgdG8gdGhlIFNwcmluZyBjb2RlYmFzZSkgd2hlbiBpdCdzIGZpbmlzaGVkPw0KCSAgICAgICAg
ICAgICAgDQoJICAgICAgICAgICAgICAgIFRyZXZvciBELiBDb29rDQoJICAgICAgICAgICAgICAg
IEludGVycHJpc2UgU29mdHdhcmUNCgkgICAgICAgICAgICAgIA0KCSAgICAgICAgICAgICAgDQoJ
ICAgICAgICAgICAgICANCgkgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCSAgICAgICAgICAgICAgICBUaGlzIHNm
Lm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6VGhpbmtHZWVrDQoJICAgICAgICAgICAgICAgIFdl
bGNvbWUgdG8gZ2VlayBoZWF2ZW4uDQoJICAgICAgICAgICAgICAgIGh0dHA6Ly90aGlua2dlZWsu
Y29tL3NmDQoJICAgICAgICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQoJICAgICAgICAgICAgICAgIFNwcmluZ2ZyYW1ld29yay1kZXZlbG9w
ZXIgbWFpbGluZyBsaXN0DQoJICAgICAgICAgICAgICAgIFNwcmluZ2ZyYW1ld29yay1kZXZlbG9w
ZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJICAgICAgICAgICAgICAgIGh0dHBzOi8vbGlzdHMu
c291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIN
CgkgICAgICAgICAgICAgIA0KCSAgICAgICANCgkgICAgICAgIE4YIFh1KRlZIGcgFyAgSHpHSiBq
Z+6iuXrtvYntt5l4y6YgRyDLsnEgeiBtP1ggKB5+encgWCBiy50/ICBqZ+uwoh167b2W7bKXDQoJ
ICAgICAgIA0KCSAgICAgICANCgkNCglOGCDpmopYJ3XevCkZIFlcZ+mirSAXIH8gYtieSB56Rygf
SiAgamfrsKIdeu29lu2yl3glUsumIChHXuyuvWggIGxxICB6bdi2P1ggKB5+encgWCBiy50/ICBq
Z+uwoh167b2W7bKXDQoJDQoJDQoNCg==

[Springframework-developer] Slogan

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

I was just reading a blog where someone mentioned that they couldn't work
out a single purpose for Spring. (They were interested in IoC so looked also
at PicoContainer.)

While the blogger clearly didn't take the time to find out what Spring
actually does, I think we should try to think about a slogan or maybe a
paragraph that conveys how it all hangs together. It's ironic in that in
comparison with something like PicoContainer, which does only a part of what
Spring does, Spring can seem to lack focus. Whereas in fact it's a focused
solution to meet infrastructure needs of real apps.

Some ideas (for concepts not wording):
- Spring provides _all_ the infrastructure most projects need
- Spring addresses all architectural tiers, whether or not you choose to use
EJB

Btw my ServerSide article should appear on October 14. I'll confirm closer
to the time, so you can watch the thread.

Regards,
Rod

RE: [Springframework-developer] Multipart File Handling

[Alef A. \(JTeam\) <al...@jt...>]

In one of my previous mails I mentioned doing something like that. It =
involved base64 encoding the byte[] to a String, after which the =
propertyeditor picked it up, decoded it again into a byte[] and set it =
on the object! Arghhh.... (as in wow that's ugly ;-).

I did this, because I rely completely on the mvc framework and 1) did =
not want to put in some MultiPart object in my object model, I just =
wanted a byte[] and 2) just didn't want to make compromises simply =
because of propertyeditors being only capable of handling Strings. Ok, =
the solution is nasty and definitely not up for adding, but I really =
think it should worked in such way that things stay consistent while on =
the other hand, not forcing a user at all to modify stuff in it's =
datamodel... May sound a bit harsh, sorry for that ;-)

Would it be possible to define a simple Spring-proprietary conversion =
interface/class which users can implement themselves capable of =
transforming multpartfile object (or whatever other type) to objects =
defined in a user's datamodel. Something like the following.

class FileUploadConvertor {
	public Object convert(MultiPartFile);
}

Just some thoughts...

Alef


-----Oorspronkelijk bericht-----
Van: spr...@li... =
[mailto:spr...@li...] Namens =
j=C3=BCrgen h=C3=B6ller [werk3AT]
Verzonden: Sunday, September 28, 2003 2:31 PM
Aan: al...@jt...; Trevor Cook; Spring Developers
Onderwerp: Re: [Springframework-developer] Multipart File Handling


Hi Alef,
=20
A PropertyEditor will always start with a String and convert it to some =
other type, in the web case applied to ServletRequest's getParameter =
values. Here we got MultipartFile instances, retrievable via =
MultipartServletRequest's getFile(String name) method: no Strings in the =
first place, thus the PropertyEditor mechanism is not applicable.
=20
We could possibly add a special check to ServletRequestDataBinder, =
binding MultipartFile instances to respective command bean fields of the =
same type in the case of a multipart request. That would work with any =
MultipartResolver implementation, as it could use the same API as manual =
file upload handling code that casts to MultipartServletRequest.
=20
Definitely a feature worth considering!
=20
Juergen
=20
=20

	-----Urspr=C3=BCngliche Nachricht-----=20
	Von: Alef Arendsen (JTeam) [mailto:al...@jt...]=20
	Gesendet: So 28.09.2003 14:04=20
	An: j=C3=BCrgen h=C3=B6ller [werk3AT]; 'Trevor Cook'; 'Spring =
Developers'=20
	Cc:=20
	Betreff: RE: [Springframework-developer] Multipart File Handling
=09
=09

	Will there be a way - using this solution - to bind the file using a =
propertyeditor (or something else maybe), just as any other command =
object is filled with parameters from the request. For consistency, I =
think that's pretty important to be consistent.
=09
	Furthermore I think it's pretty cool if the fileupload could be fixed =
before the 1.0 release! Good thing!
=09
	Alef
=09
=09
	-----Oorspronkelijk bericht-----
	Van: spr...@li... =
[mailto:spr...@li...] Namens =
j=C3=BCrgen h=C3=B6ller [werk3AT]
	Verzonden: Sunday, September 28, 2003 12:33 PM
	Aan: Trevor Cook; Spring Developers
	Onderwerp: Re: [Springframework-developer] Multipart File Handling
=09
=09
	Hi Trevor,
=09
	A MultipartResolver interface with implementations for Commons =
FileUpload and COS is fine with me - it just hadn't high priority since =
I proposed it half a year ago. As I still have a pretty clear picture of =
the issues, I'll be happy to review your code once you've checked it in. =
As this should be pretty straightforward, let's try to include this =
already in 1.0 M2 - at least with a Commons FileUpload implementation.
=09
	BTW, in contrast to COS, Commons FileUpload doesn't provide a Servlet =
2.3 filter anyway. This means that there would be some infrastructure =
code to write for that use case too, even when using standard filters. A =
simple but convenient Spring solution would definitely be a good thing.
=09
	Juergen
=09
=09
=09
=09
	        -----Urspr=C3=BCngliche Nachricht-----
	        Von: Trevor Cook [mailto:pr...@se...]
	        Gesendet: Sa 27.09.2003 19:35
	        An: Spring Developers
	        Cc:
	        Betreff: [[W3-SPAM]] - [Springframework-developer] Multipart =
File Handling - Email found in subject
	      =20
	      =20
=09
	        First some history:
	        http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279
	        http://sourceforge.net/mailarchive/message.php?msg_id=3D5175276
	        =
http://sourceforge.net/mailarchive/forum.php?thread_id=3D3125561&forum_id=
=3D3028
	        7
	        http://sourceforge.net/mailarchive/message.php?msg_id=3D6062288
	      =20
	        To address a few things Juergen mentioned previously.
	      =20
	        >> a less intrusive way would be to wrap the HttpServletRequest =
via a filter
	        I personally don't like the filter approach, at least for the =
framework.  It
	        requires additional setup for the user (in the web.xml file) =
and might be
	        less understandable since our normal strategy so far has been =
with resolvers
	        inside the servlet.
	      =20
	        >>we would need to find concrete requirements for this
	        We have numerous uses for file upload handling.  We have a =
public photo
	        contest where users can upload fotos.  We have special access =
for suppliers
	        to upload product files (csv) which we then add in to our =
ordering system.
	        Finally, we have a web administration interface which allows =
our client to
	        upload files to the website so they can be downloaded.  I think =
that
	        including this support (multipart handling) is a no-brainer.
	      =20
	        Basically, I have used COS exclusively in our projects, but I =
don't think
	        that's easy for Spring to use (due to the licensing).  I would =
simply code
	        this according to Spring norms using an interface and a default =
version
	        using Commons FileUpload.  Later, if somebody wants to create a =
cos version
	        we can (but to be honest, if we have a working, integrated =
solution I'm not
	        sure that is necessary - at least not in the Spring framework). =
 Basically,
	        provide hooks and a default implementation, and allow users to =
adopt as
	        necessary.
	      =20
	        In our project we had modified the AbstractController and put =
the code into
	        it to handle the multipart processing, returning a wrapped
	        HttpServletRequest through the handlers.  This is very similiar =
to Juergen's
	        outline =
(http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279).
	      =20
	        Since we are migrating to the current Spring codebase, I need =
to move our
	        multipart handling code.  The main question is whether we keep =
it
	        internally, or place it into Spring.  I propose modifying
	        org.springframework.web.servlet.DispatcherServlet to have a
	        "MultipartResolver".  In the DispatcherServlet, the resolver =
would be called
	        to wrap the request in doService immediately before =
getHandler(request) -
	        currently line 351, and then called to do any cleanup =
immediately before
	        exiting the doService method.
	      =20
	        I have about 2/3 of the code already written, and I will be =
writing the rest
	        between now and Monday.  Does this strategy sound appropriate =
for Spring
	        (meaning should I commit it to the Spring codebase) when it's =
finished?
	      =20
	        Trevor D. Cook
	        Interprise Software
	      =20
	      =20
	      =20
	        -------------------------------------------------------
	        This sf.net email is sponsored by:ThinkGeek
	        Welcome to geek heaven.
	        http://thinkgeek.com/sf
	        _______________________________________________
	        Springframework-developer mailing list
	        Spr...@li...
	        =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
	      =20
=09
	N=18 Xu)=19Y g =17  HzGJ jg=EE=A2=B9z=ED=BD=89=ED=B7=99x=CB=A6 G =
=CB=B2q z m?X (=1E~zw X b=CB=9D?  jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97
=09
=09

N=18 =E9=9A=8AX'u=DE=BC)=19 Y\g=E9=A2=AD =17 =7F b=D8=9EH=1EzG(=1FJ  =
jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97x%R=CB=A6 (G^=EC=AE=BDh  lq  zm=D8=B6?X =
(=1E~zw X b=CB=9D?  jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97

[Springframework-developer] Testing JavaMail

[Alef A. \(JTeam\) <al...@jt...>]

I've taken a look at the JavaMail package and it's tested right now.
However, I could not find the mailer we used internally anymore, so I've
snatched another mockup mailserver form the net. However, the library is
licensed under GPL. I've never really understood how to handle GPL
licenses when you're just using the library for testing purposes and
stuff... Any objections?

Furthermore, I was wondering why not all of the properties JavaMail
specified can be set in the MailSetings object. For instance
mail.smtp.port cannot be set?

Any comments?

Alef

P.s. the mail library is located at
http://sourceforge.net/projects/dumbster

-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens
Rod Johnson
Verzonden: Tuesday, September 23, 2003 8:50 AM
Aan: al...@jt...; spr...@li...
Onderwerp: Re: [Springframework-developer] Test coverage


I took a look and mocking JavaMail isn't really an option (superbly
untestable API, with static methods and final classes).

So this is probably the only way to go... Thanks.

Regards,
Rod

----- Original Message ----- 
From: "Alef Arendsen (JTeam)" <al...@jt...>
To: "'Rod Johnson'" <rod...@in...>;
<spr...@li...>
Sent: Monday, September 22, 2003 10:48 PM
Subject: RE: [Springframework-developer] Test coverage


> If nobody's busy doing it already, I'll see what I can do on the 
> javamail package. I've got a devnull mailer lying around somewhere 
> that we use for testing, maybe I can integrate it somehow...
>
> By the way, up to 76,7 now...
>
> Alef
>
> -----Oorspronkelijk bericht-----
> Van: spr...@li...
> [mailto:spr...@li...] Namens 
> Rod Johnson
> Verzonden: Saturday, September 20, 2003 11:17 PM
> Aan: spr...@li...
> Onderwerp: [Springframework-developer] Test coverage
>
>
> I think one of the things that has contributed to the success and 
> quality of Spring is our commitment to a good test suite. I've put a 
> fair bit more work into the test suite over the weekend, with the 
> upgrade to EasyMock 1.0 and new test suites for Velocity etc.
>
> I'm really pleased that everyone is emphasising tests in new coding, 
> but there is a still a bit of catchup to do.
>
> With this and Alef's new tag tests, test coverage is now 75.8%. I'd 
> like to see this go above 80% before 1.0RC1.
>
> So I think we should all kick in and add tests to our areas of 
> interest. Please run the Clover analysis as a starting point.
>
> Current major gaps include:
> - XSLT support. I wrote this code so I guess I really should do the 
> tests but I'm not sure I have time. (These days I work entirely test 
> first, but I wrote that last year.) If any of the dev team are using 
> this, maybe they could take a look? It might require some refactoring.
> - jdbc.core.support: No tests for incrementer support. Can the 
> developers looking after this please try to add some tests?
>
> Any volunteers for these or other areas in which tests can be 
> improved?
>
> Regards,
> Rod
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf 
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Multipart File Handling

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

>Will there be a way - using this solution - to bind the file using a
propertyeditor (or something else maybe), just as any other command object
is filled with parameters from the request. For consistency, I think that's
pretty important to be consistent.

Now that _would_ be nice.

Re: [Springframework-developer] Multipart File Handling

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

SGkgQWxlZiwNCiANCkEgUHJvcGVydHlFZGl0b3Igd2lsbCBhbHdheXMgc3RhcnQgd2l0aCBhIFN0
cmluZyBhbmQgY29udmVydCBpdCB0byBzb21lIG90aGVyIHR5cGUsIGluIHRoZSB3ZWIgY2FzZSBh
cHBsaWVkIHRvIFNlcnZsZXRSZXF1ZXN0J3MgZ2V0UGFyYW1ldGVyIHZhbHVlcy4gSGVyZSB3ZSBn
b3QgTXVsdGlwYXJ0RmlsZSBpbnN0YW5jZXMsIHJldHJpZXZhYmxlIHZpYSBNdWx0aXBhcnRTZXJ2
bGV0UmVxdWVzdCdzIGdldEZpbGUoU3RyaW5nIG5hbWUpIG1ldGhvZDogbm8gU3RyaW5ncyBpbiB0
aGUgZmlyc3QgcGxhY2UsIHRodXMgdGhlIFByb3BlcnR5RWRpdG9yIG1lY2hhbmlzbSBpcyBub3Qg
YXBwbGljYWJsZS4NCiANCldlIGNvdWxkIHBvc3NpYmx5IGFkZCBhIHNwZWNpYWwgY2hlY2sgdG8g
U2VydmxldFJlcXVlc3REYXRhQmluZGVyLCBiaW5kaW5nIE11bHRpcGFydEZpbGUgaW5zdGFuY2Vz
IHRvIHJlc3BlY3RpdmUgY29tbWFuZCBiZWFuIGZpZWxkcyBvZiB0aGUgc2FtZSB0eXBlIGluIHRo
ZSBjYXNlIG9mIGEgbXVsdGlwYXJ0IHJlcXVlc3QuIFRoYXQgd291bGQgd29yayB3aXRoIGFueSBN
dWx0aXBhcnRSZXNvbHZlciBpbXBsZW1lbnRhdGlvbiwgYXMgaXQgY291bGQgdXNlIHRoZSBzYW1l
IEFQSSBhcyBtYW51YWwgZmlsZSB1cGxvYWQgaGFuZGxpbmcgY29kZSB0aGF0IGNhc3RzIHRvIE11
bHRpcGFydFNlcnZsZXRSZXF1ZXN0Lg0KIA0KRGVmaW5pdGVseSBhIGZlYXR1cmUgd29ydGggY29u
c2lkZXJpbmchDQogDQpKdWVyZ2VuDQogDQogDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hy
aWNodC0tLS0tIA0KCVZvbjogQWxlZiBBcmVuZHNlbiAoSlRlYW0pIFttYWlsdG86YWxlZkBqdGVh
bS5ubF0gDQoJR2VzZW5kZXQ6IFNvIDI4LjA5LjIwMDMgMTQ6MDQgDQoJQW46IGrDvHJnZW4gaMO2
bGxlciBbd2VyazNBVF07ICdUcmV2b3IgQ29vayc7ICdTcHJpbmcgRGV2ZWxvcGVycycgDQoJQ2M6
IA0KCUJldHJlZmY6IFJFOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gTXVsdGlwYXJ0IEZp
bGUgSGFuZGxpbmcNCgkNCgkNCg0KCVdpbGwgdGhlcmUgYmUgYSB3YXkgLSB1c2luZyB0aGlzIHNv
bHV0aW9uIC0gdG8gYmluZCB0aGUgZmlsZSB1c2luZyBhIHByb3BlcnR5ZWRpdG9yIChvciBzb21l
dGhpbmcgZWxzZSBtYXliZSksIGp1c3QgYXMgYW55IG90aGVyIGNvbW1hbmQgb2JqZWN0IGlzIGZp
bGxlZCB3aXRoIHBhcmFtZXRlcnMgZnJvbSB0aGUgcmVxdWVzdC4gRm9yIGNvbnNpc3RlbmN5LCBJ
IHRoaW5rIHRoYXQncyBwcmV0dHkgaW1wb3J0YW50IHRvIGJlIGNvbnNpc3RlbnQuDQoJDQoJRnVy
dGhlcm1vcmUgSSB0aGluayBpdCdzIHByZXR0eSBjb29sIGlmIHRoZSBmaWxldXBsb2FkIGNvdWxk
IGJlIGZpeGVkIGJlZm9yZSB0aGUgMS4wIHJlbGVhc2UhIEdvb2QgdGhpbmchDQoJDQoJQWxlZg0K
CQ0KCQ0KCS0tLS0tT29yc3Byb25rZWxpamsgYmVyaWNodC0tLS0tDQoJVmFuOiBzcHJpbmdmcmFt
ZXdvcmstZGV2ZWxvcGVyLWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCBbbWFpbHRvOnNwcmlu
Z2ZyYW1ld29yay1kZXZlbG9wZXItYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0XSBOYW1lbnMg
asO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXQ0KCVZlcnpvbmRlbjogU3VuZGF5LCBTZXB0ZW1iZXIg
MjgsIDIwMDMgMTI6MzMgUE0NCglBYW46IFRyZXZvciBDb29rOyBTcHJpbmcgRGV2ZWxvcGVycw0K
CU9uZGVyd2VycDogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBNdWx0aXBhcnQgRmls
ZSBIYW5kbGluZw0KCQ0KCQ0KCUhpIFRyZXZvciwNCgkNCglBIE11bHRpcGFydFJlc29sdmVyIGlu
dGVyZmFjZSB3aXRoIGltcGxlbWVudGF0aW9ucyBmb3IgQ29tbW9ucyBGaWxlVXBsb2FkIGFuZCBD
T1MgaXMgZmluZSB3aXRoIG1lIC0gaXQganVzdCBoYWRuJ3QgaGlnaCBwcmlvcml0eSBzaW5jZSBJ
IHByb3Bvc2VkIGl0IGhhbGYgYSB5ZWFyIGFnby4gQXMgSSBzdGlsbCBoYXZlIGEgcHJldHR5IGNs
ZWFyIHBpY3R1cmUgb2YgdGhlIGlzc3VlcywgSSdsbCBiZSBoYXBweSB0byByZXZpZXcgeW91ciBj
b2RlIG9uY2UgeW91J3ZlIGNoZWNrZWQgaXQgaW4uIEFzIHRoaXMgc2hvdWxkIGJlIHByZXR0eSBz
dHJhaWdodGZvcndhcmQsIGxldCdzIHRyeSB0byBpbmNsdWRlIHRoaXMgYWxyZWFkeSBpbiAxLjAg
TTIgLSBhdCBsZWFzdCB3aXRoIGEgQ29tbW9ucyBGaWxlVXBsb2FkIGltcGxlbWVudGF0aW9uLg0K
CQ0KCUJUVywgaW4gY29udHJhc3QgdG8gQ09TLCBDb21tb25zIEZpbGVVcGxvYWQgZG9lc24ndCBw
cm92aWRlIGEgU2VydmxldCAyLjMgZmlsdGVyIGFueXdheS4gVGhpcyBtZWFucyB0aGF0IHRoZXJl
IHdvdWxkIGJlIHNvbWUgaW5mcmFzdHJ1Y3R1cmUgY29kZSB0byB3cml0ZSBmb3IgdGhhdCB1c2Ug
Y2FzZSB0b28sIGV2ZW4gd2hlbiB1c2luZyBzdGFuZGFyZCBmaWx0ZXJzLiBBIHNpbXBsZSBidXQg
Y29udmVuaWVudCBTcHJpbmcgc29sdXRpb24gd291bGQgZGVmaW5pdGVseSBiZSBhIGdvb2QgdGhp
bmcuDQoJDQoJSnVlcmdlbg0KCQ0KCQ0KCQ0KCQ0KCSAgICAgICAgLS0tLS1VcnNwcsO8bmdsaWNo
ZSBOYWNocmljaHQtLS0tLQ0KCSAgICAgICAgVm9uOiBUcmV2b3IgQ29vayBbbWFpbHRvOnByaXNl
MDNAc2VudGV4Lm5ldF0NCgkgICAgICAgIEdlc2VuZGV0OiBTYSAyNy4wOS4yMDAzIDE5OjM1DQoJ
ICAgICAgICBBbjogU3ByaW5nIERldmVsb3BlcnMNCgkgICAgICAgIENjOg0KCSAgICAgICAgQmV0
cmVmZjogW1tXMy1TUEFNXV0gLSBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gTXVsdGlwYXJ0
IEZpbGUgSGFuZGxpbmcgLSBFbWFpbCBmb3VuZCBpbiBzdWJqZWN0DQoJICAgICAgIA0KCSAgICAg
ICANCgkNCgkgICAgICAgIEZpcnN0IHNvbWUgaGlzdG9yeToNCgkgICAgICAgIGh0dHA6Ly9zb3Vy
Y2Vmb3JnZS5uZXQvbWFpbGFyY2hpdmUvbWVzc2FnZS5waHA/bXNnX2lkPTM4OTEyNzkNCgkgICAg
ICAgIGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvbWFpbGFyY2hpdmUvbWVzc2FnZS5waHA/bXNnX2lk
PTUxNzUyNzYNCgkgICAgICAgIGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvbWFpbGFyY2hpdmUvZm9y
dW0ucGhwP3RocmVhZF9pZD0zMTI1NTYxJmZvcnVtX2lkPTMwMjgNCgkgICAgICAgIDcNCgkgICAg
ICAgIGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvbWFpbGFyY2hpdmUvbWVzc2FnZS5waHA/bXNnX2lk
PTYwNjIyODgNCgkgICAgICAgDQoJICAgICAgICBUbyBhZGRyZXNzIGEgZmV3IHRoaW5ncyBKdWVy
Z2VuIG1lbnRpb25lZCBwcmV2aW91c2x5Lg0KCSAgICAgICANCgkgICAgICAgID4+IGEgbGVzcyBp
bnRydXNpdmUgd2F5IHdvdWxkIGJlIHRvIHdyYXAgdGhlIEh0dHBTZXJ2bGV0UmVxdWVzdCB2aWEg
YSBmaWx0ZXINCgkgICAgICAgIEkgcGVyc29uYWxseSBkb24ndCBsaWtlIHRoZSBmaWx0ZXIgYXBw
cm9hY2gsIGF0IGxlYXN0IGZvciB0aGUgZnJhbWV3b3JrLiAgSXQNCgkgICAgICAgIHJlcXVpcmVz
IGFkZGl0aW9uYWwgc2V0dXAgZm9yIHRoZSB1c2VyIChpbiB0aGUgd2ViLnhtbCBmaWxlKSBhbmQg
bWlnaHQgYmUNCgkgICAgICAgIGxlc3MgdW5kZXJzdGFuZGFibGUgc2luY2Ugb3VyIG5vcm1hbCBz
dHJhdGVneSBzbyBmYXIgaGFzIGJlZW4gd2l0aCByZXNvbHZlcnMNCgkgICAgICAgIGluc2lkZSB0
aGUgc2VydmxldC4NCgkgICAgICAgDQoJICAgICAgICA+PndlIHdvdWxkIG5lZWQgdG8gZmluZCBj
b25jcmV0ZSByZXF1aXJlbWVudHMgZm9yIHRoaXMNCgkgICAgICAgIFdlIGhhdmUgbnVtZXJvdXMg
dXNlcyBmb3IgZmlsZSB1cGxvYWQgaGFuZGxpbmcuICBXZSBoYXZlIGEgcHVibGljIHBob3RvDQoJ
ICAgICAgICBjb250ZXN0IHdoZXJlIHVzZXJzIGNhbiB1cGxvYWQgZm90b3MuICBXZSBoYXZlIHNw
ZWNpYWwgYWNjZXNzIGZvciBzdXBwbGllcnMNCgkgICAgICAgIHRvIHVwbG9hZCBwcm9kdWN0IGZp
bGVzIChjc3YpIHdoaWNoIHdlIHRoZW4gYWRkIGluIHRvIG91ciBvcmRlcmluZyBzeXN0ZW0uDQoJ
ICAgICAgICBGaW5hbGx5LCB3ZSBoYXZlIGEgd2ViIGFkbWluaXN0cmF0aW9uIGludGVyZmFjZSB3
aGljaCBhbGxvd3Mgb3VyIGNsaWVudCB0bw0KCSAgICAgICAgdXBsb2FkIGZpbGVzIHRvIHRoZSB3
ZWJzaXRlIHNvIHRoZXkgY2FuIGJlIGRvd25sb2FkZWQuICBJIHRoaW5rIHRoYXQNCgkgICAgICAg
IGluY2x1ZGluZyB0aGlzIHN1cHBvcnQgKG11bHRpcGFydCBoYW5kbGluZykgaXMgYSBuby1icmFp
bmVyLg0KCSAgICAgICANCgkgICAgICAgIEJhc2ljYWxseSwgSSBoYXZlIHVzZWQgQ09TIGV4Y2x1
c2l2ZWx5IGluIG91ciBwcm9qZWN0cywgYnV0IEkgZG9uJ3QgdGhpbmsNCgkgICAgICAgIHRoYXQn
cyBlYXN5IGZvciBTcHJpbmcgdG8gdXNlIChkdWUgdG8gdGhlIGxpY2Vuc2luZykuICBJIHdvdWxk
IHNpbXBseSBjb2RlDQoJICAgICAgICB0aGlzIGFjY29yZGluZyB0byBTcHJpbmcgbm9ybXMgdXNp
bmcgYW4gaW50ZXJmYWNlIGFuZCBhIGRlZmF1bHQgdmVyc2lvbg0KCSAgICAgICAgdXNpbmcgQ29t
bW9ucyBGaWxlVXBsb2FkLiAgTGF0ZXIsIGlmIHNvbWVib2R5IHdhbnRzIHRvIGNyZWF0ZSBhIGNv
cyB2ZXJzaW9uDQoJICAgICAgICB3ZSBjYW4gKGJ1dCB0byBiZSBob25lc3QsIGlmIHdlIGhhdmUg
YSB3b3JraW5nLCBpbnRlZ3JhdGVkIHNvbHV0aW9uIEknbSBub3QNCgkgICAgICAgIHN1cmUgdGhh
dCBpcyBuZWNlc3NhcnkgLSBhdCBsZWFzdCBub3QgaW4gdGhlIFNwcmluZyBmcmFtZXdvcmspLiAg
QmFzaWNhbGx5LA0KCSAgICAgICAgcHJvdmlkZSBob29rcyBhbmQgYSBkZWZhdWx0IGltcGxlbWVu
dGF0aW9uLCBhbmQgYWxsb3cgdXNlcnMgdG8gYWRvcHQgYXMNCgkgICAgICAgIG5lY2Vzc2FyeS4N
CgkgICAgICAgDQoJICAgICAgICBJbiBvdXIgcHJvamVjdCB3ZSBoYWQgbW9kaWZpZWQgdGhlIEFi
c3RyYWN0Q29udHJvbGxlciBhbmQgcHV0IHRoZSBjb2RlIGludG8NCgkgICAgICAgIGl0IHRvIGhh
bmRsZSB0aGUgbXVsdGlwYXJ0IHByb2Nlc3NpbmcsIHJldHVybmluZyBhIHdyYXBwZWQNCgkgICAg
ICAgIEh0dHBTZXJ2bGV0UmVxdWVzdCB0aHJvdWdoIHRoZSBoYW5kbGVycy4gIFRoaXMgaXMgdmVy
eSBzaW1pbGlhciB0byBKdWVyZ2VuJ3MNCgkgICAgICAgIG91dGxpbmUgKGh0dHA6Ly9zb3VyY2Vm
b3JnZS5uZXQvbWFpbGFyY2hpdmUvbWVzc2FnZS5waHA/bXNnX2lkPTM4OTEyNzkpLg0KCSAgICAg
ICANCgkgICAgICAgIFNpbmNlIHdlIGFyZSBtaWdyYXRpbmcgdG8gdGhlIGN1cnJlbnQgU3ByaW5n
IGNvZGViYXNlLCBJIG5lZWQgdG8gbW92ZSBvdXINCgkgICAgICAgIG11bHRpcGFydCBoYW5kbGlu
ZyBjb2RlLiAgVGhlIG1haW4gcXVlc3Rpb24gaXMgd2hldGhlciB3ZSBrZWVwIGl0DQoJICAgICAg
ICBpbnRlcm5hbGx5LCBvciBwbGFjZSBpdCBpbnRvIFNwcmluZy4gIEkgcHJvcG9zZSBtb2RpZnlp
bmcNCgkgICAgICAgIG9yZy5zcHJpbmdmcmFtZXdvcmsud2ViLnNlcnZsZXQuRGlzcGF0Y2hlclNl
cnZsZXQgdG8gaGF2ZSBhDQoJICAgICAgICAiTXVsdGlwYXJ0UmVzb2x2ZXIiLiAgSW4gdGhlIERp
c3BhdGNoZXJTZXJ2bGV0LCB0aGUgcmVzb2x2ZXIgd291bGQgYmUgY2FsbGVkDQoJICAgICAgICB0
byB3cmFwIHRoZSByZXF1ZXN0IGluIGRvU2VydmljZSBpbW1lZGlhdGVseSBiZWZvcmUgZ2V0SGFu
ZGxlcihyZXF1ZXN0KSAtDQoJICAgICAgICBjdXJyZW50bHkgbGluZSAzNTEsIGFuZCB0aGVuIGNh
bGxlZCB0byBkbyBhbnkgY2xlYW51cCBpbW1lZGlhdGVseSBiZWZvcmUNCgkgICAgICAgIGV4aXRp
bmcgdGhlIGRvU2VydmljZSBtZXRob2QuDQoJICAgICAgIA0KCSAgICAgICAgSSBoYXZlIGFib3V0
IDIvMyBvZiB0aGUgY29kZSBhbHJlYWR5IHdyaXR0ZW4sIGFuZCBJIHdpbGwgYmUgd3JpdGluZyB0
aGUgcmVzdA0KCSAgICAgICAgYmV0d2VlbiBub3cgYW5kIE1vbmRheS4gIERvZXMgdGhpcyBzdHJh
dGVneSBzb3VuZCBhcHByb3ByaWF0ZSBmb3IgU3ByaW5nDQoJICAgICAgICAobWVhbmluZyBzaG91
bGQgSSBjb21taXQgaXQgdG8gdGhlIFNwcmluZyBjb2RlYmFzZSkgd2hlbiBpdCdzIGZpbmlzaGVk
Pw0KCSAgICAgICANCgkgICAgICAgIFRyZXZvciBELiBDb29rDQoJICAgICAgICBJbnRlcnByaXNl
IFNvZnR3YXJlDQoJICAgICAgIA0KCSAgICAgICANCgkgICAgICAgDQoJICAgICAgICAtLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJICAgICAg
ICBUaGlzIHNmLm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6VGhpbmtHZWVrDQoJICAgICAgICBX
ZWxjb21lIHRvIGdlZWsgaGVhdmVuLg0KCSAgICAgICAgaHR0cDovL3RoaW5rZ2Vlay5jb20vc2YN
CgkgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQoJICAgICAgICBTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxpbmcgbGlzdA0KCSAgICAg
ICAgU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCgkgICAg
ICAgIGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3NwcmluZ2Zy
YW1ld29yay1kZXZlbG9wZXINCgkgICAgICAgDQoJDQoJThggWHUpGVkgZyAXICBIekdKIGpn7qK5
eu29ie23mXjLpiBHIMuycSB6IG0/WCAoHn56dyBYIGLLnT8gIGpn67CiHXrtvZbtspcNCgkNCgkN
Cg0K

RE: [Springframework-developer] Multipart File Handling

[Alef A. \(JTeam\) <al...@jt...>]

Will there be a way - using this solution - to bind the file using a =
propertyeditor (or something else maybe), just as any other command =
object is filled with parameters from the request. For consistency, I =
think that's pretty important to be consistent.

Furthermore I think it's pretty cool if the fileupload could be fixed =
before the 1.0 release! Good thing!

Alef


-----Oorspronkelijk bericht-----
Van: spr...@li... =
[mailto:spr...@li...] Namens =
j=C3=BCrgen h=C3=B6ller [werk3AT]
Verzonden: Sunday, September 28, 2003 12:33 PM
Aan: Trevor Cook; Spring Developers
Onderwerp: Re: [Springframework-developer] Multipart File Handling


Hi Trevor,
=20
A MultipartResolver interface with implementations for Commons =
FileUpload and COS is fine with me - it just hadn't high priority since =
I proposed it half a year ago. As I still have a pretty clear picture of =
the issues, I'll be happy to review your code once you've checked it in. =
As this should be pretty straightforward, let's try to include this =
already in 1.0 M2 - at least with a Commons FileUpload implementation.
=20
BTW, in contrast to COS, Commons FileUpload doesn't provide a Servlet =
2.3 filter anyway. This means that there would be some infrastructure =
code to write for that use case too, even when using standard filters. A =
simple but convenient Spring solution would definitely be a good thing.
=20
Juergen
=20
=20
=20

	-----Urspr=C3=BCngliche Nachricht-----=20
	Von: Trevor Cook [mailto:pr...@se...]=20
	Gesendet: Sa 27.09.2003 19:35=20
	An: Spring Developers=20
	Cc:=20
	Betreff: [[W3-SPAM]] - [Springframework-developer] Multipart File =
Handling - Email found in subject
=09
=09

	First some history:
	http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279
	http://sourceforge.net/mailarchive/message.php?msg_id=3D5175276
	=
http://sourceforge.net/mailarchive/forum.php?thread_id=3D3125561&forum_id=
=3D3028
	7
	http://sourceforge.net/mailarchive/message.php?msg_id=3D6062288
=09
	To address a few things Juergen mentioned previously.
=09
	>> a less intrusive way would be to wrap the HttpServletRequest via a =
filter
	I personally don't like the filter approach, at least for the =
framework.  It
	requires additional setup for the user (in the web.xml file) and might =
be
	less understandable since our normal strategy so far has been with =
resolvers
	inside the servlet.
=09
	>>we would need to find concrete requirements for this
	We have numerous uses for file upload handling.  We have a public photo
	contest where users can upload fotos.  We have special access for =
suppliers
	to upload product files (csv) which we then add in to our ordering =
system.
	Finally, we have a web administration interface which allows our client =
to
	upload files to the website so they can be downloaded.  I think that
	including this support (multipart handling) is a no-brainer.
=09
	Basically, I have used COS exclusively in our projects, but I don't =
think
	that's easy for Spring to use (due to the licensing).  I would simply =
code
	this according to Spring norms using an interface and a default version
	using Commons FileUpload.  Later, if somebody wants to create a cos =
version
	we can (but to be honest, if we have a working, integrated solution I'm =
not
	sure that is necessary - at least not in the Spring framework).  =
Basically,
	provide hooks and a default implementation, and allow users to adopt as
	necessary.
=09
	In our project we had modified the AbstractController and put the code =
into
	it to handle the multipart processing, returning a wrapped
	HttpServletRequest through the handlers.  This is very similiar to =
Juergen's
	outline =
(http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279).
=09
	Since we are migrating to the current Spring codebase, I need to move =
our
	multipart handling code.  The main question is whether we keep it
	internally, or place it into Spring.  I propose modifying
	org.springframework.web.servlet.DispatcherServlet to have a
	"MultipartResolver".  In the DispatcherServlet, the resolver would be =
called
	to wrap the request in doService immediately before getHandler(request) =
-
	currently line 351, and then called to do any cleanup immediately =
before
	exiting the doService method.
=09
	I have about 2/3 of the code already written, and I will be writing the =
rest
	between now and Monday.  Does this strategy sound appropriate for =
Spring
	(meaning should I commit it to the Spring codebase) when it's finished?
=09
	Trevor D. Cook
	Interprise Software
=09
=09
=09
	-------------------------------------------------------
	This sf.net email is sponsored by:ThinkGeek
	Welcome to geek heaven.
	http://thinkgeek.com/sf
	_______________________________________________
	Springframework-developer mailing list
	Spr...@li...
	https://lists.sourceforge.net/lists/listinfo/springframework-developer
=09

N=18 Xu)=19Y g =17  HzGJ jg=EE=A2=B9z=ED=BD=89=ED=B7=99x=CB=A6 G =CB=B2q =
z m?X (=1E~zw X b=CB=9D?  jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97

Re: [Springframework-developer] Multipart File Handling

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

SGkgVHJldm9yLA0KIA0KQSBNdWx0aXBhcnRSZXNvbHZlciBpbnRlcmZhY2Ugd2l0aCBpbXBsZW1l
bnRhdGlvbnMgZm9yIENvbW1vbnMgRmlsZVVwbG9hZCBhbmQgQ09TIGlzIGZpbmUgd2l0aCBtZSAt
IGl0IGp1c3QgaGFkbid0IGhpZ2ggcHJpb3JpdHkgc2luY2UgSSBwcm9wb3NlZCBpdCBoYWxmIGEg
eWVhciBhZ28uIEFzIEkgc3RpbGwgaGF2ZSBhIHByZXR0eSBjbGVhciBwaWN0dXJlIG9mIHRoZSBp
c3N1ZXMsIEknbGwgYmUgaGFwcHkgdG8gcmV2aWV3IHlvdXIgY29kZSBvbmNlIHlvdSd2ZSBjaGVj
a2VkIGl0IGluLiBBcyB0aGlzIHNob3VsZCBiZSBwcmV0dHkgc3RyYWlnaHRmb3J3YXJkLCBsZXQn
cyB0cnkgdG8gaW5jbHVkZSB0aGlzIGFscmVhZHkgaW4gMS4wIE0yIC0gYXQgbGVhc3Qgd2l0aCBh
IENvbW1vbnMgRmlsZVVwbG9hZCBpbXBsZW1lbnRhdGlvbi4NCiANCkJUVywgaW4gY29udHJhc3Qg
dG8gQ09TLCBDb21tb25zIEZpbGVVcGxvYWQgZG9lc24ndCBwcm92aWRlIGEgU2VydmxldCAyLjMg
ZmlsdGVyIGFueXdheS4gVGhpcyBtZWFucyB0aGF0IHRoZXJlIHdvdWxkIGJlIHNvbWUgaW5mcmFz
dHJ1Y3R1cmUgY29kZSB0byB3cml0ZSBmb3IgdGhhdCB1c2UgY2FzZSB0b28sIGV2ZW4gd2hlbiB1
c2luZyBzdGFuZGFyZCBmaWx0ZXJzLiBBIHNpbXBsZSBidXQgY29udmVuaWVudCBTcHJpbmcgc29s
dXRpb24gd291bGQgZGVmaW5pdGVseSBiZSBhIGdvb2QgdGhpbmcuDQogDQpKdWVyZ2VuDQogDQog
DQogDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjogVHJldm9y
IENvb2sgW21haWx0bzpwcmlzZTAzQHNlbnRleC5uZXRdIA0KCUdlc2VuZGV0OiBTYSAyNy4wOS4y
MDAzIDE5OjM1IA0KCUFuOiBTcHJpbmcgRGV2ZWxvcGVycyANCglDYzogDQoJQmV0cmVmZjogW1tX
My1TUEFNXV0gLSBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gTXVsdGlwYXJ0IEZpbGUgSGFu
ZGxpbmcgLSBFbWFpbCBmb3VuZCBpbiBzdWJqZWN0DQoJDQoJDQoNCglGaXJzdCBzb21lIGhpc3Rv
cnk6DQoJaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9tYWlsYXJjaGl2ZS9tZXNzYWdlLnBocD9tc2df
aWQ9Mzg5MTI3OQ0KCWh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvbWFpbGFyY2hpdmUvbWVzc2FnZS5w
aHA/bXNnX2lkPTUxNzUyNzYNCglodHRwOi8vc291cmNlZm9yZ2UubmV0L21haWxhcmNoaXZlL2Zv
cnVtLnBocD90aHJlYWRfaWQ9MzEyNTU2MSZmb3J1bV9pZD0zMDI4DQoJNw0KCWh0dHA6Ly9zb3Vy
Y2Vmb3JnZS5uZXQvbWFpbGFyY2hpdmUvbWVzc2FnZS5waHA/bXNnX2lkPTYwNjIyODgNCgkNCglU
byBhZGRyZXNzIGEgZmV3IHRoaW5ncyBKdWVyZ2VuIG1lbnRpb25lZCBwcmV2aW91c2x5Lg0KCQ0K
CT4+IGEgbGVzcyBpbnRydXNpdmUgd2F5IHdvdWxkIGJlIHRvIHdyYXAgdGhlIEh0dHBTZXJ2bGV0
UmVxdWVzdCB2aWEgYSBmaWx0ZXINCglJIHBlcnNvbmFsbHkgZG9uJ3QgbGlrZSB0aGUgZmlsdGVy
IGFwcHJvYWNoLCBhdCBsZWFzdCBmb3IgdGhlIGZyYW1ld29yay4gIEl0DQoJcmVxdWlyZXMgYWRk
aXRpb25hbCBzZXR1cCBmb3IgdGhlIHVzZXIgKGluIHRoZSB3ZWIueG1sIGZpbGUpIGFuZCBtaWdo
dCBiZQ0KCWxlc3MgdW5kZXJzdGFuZGFibGUgc2luY2Ugb3VyIG5vcm1hbCBzdHJhdGVneSBzbyBm
YXIgaGFzIGJlZW4gd2l0aCByZXNvbHZlcnMNCglpbnNpZGUgdGhlIHNlcnZsZXQuDQoJDQoJPj53
ZSB3b3VsZCBuZWVkIHRvIGZpbmQgY29uY3JldGUgcmVxdWlyZW1lbnRzIGZvciB0aGlzDQoJV2Ug
aGF2ZSBudW1lcm91cyB1c2VzIGZvciBmaWxlIHVwbG9hZCBoYW5kbGluZy4gIFdlIGhhdmUgYSBw
dWJsaWMgcGhvdG8NCgljb250ZXN0IHdoZXJlIHVzZXJzIGNhbiB1cGxvYWQgZm90b3MuICBXZSBo
YXZlIHNwZWNpYWwgYWNjZXNzIGZvciBzdXBwbGllcnMNCgl0byB1cGxvYWQgcHJvZHVjdCBmaWxl
cyAoY3N2KSB3aGljaCB3ZSB0aGVuIGFkZCBpbiB0byBvdXIgb3JkZXJpbmcgc3lzdGVtLg0KCUZp
bmFsbHksIHdlIGhhdmUgYSB3ZWIgYWRtaW5pc3RyYXRpb24gaW50ZXJmYWNlIHdoaWNoIGFsbG93
cyBvdXIgY2xpZW50IHRvDQoJdXBsb2FkIGZpbGVzIHRvIHRoZSB3ZWJzaXRlIHNvIHRoZXkgY2Fu
IGJlIGRvd25sb2FkZWQuICBJIHRoaW5rIHRoYXQNCglpbmNsdWRpbmcgdGhpcyBzdXBwb3J0ICht
dWx0aXBhcnQgaGFuZGxpbmcpIGlzIGEgbm8tYnJhaW5lci4NCgkNCglCYXNpY2FsbHksIEkgaGF2
ZSB1c2VkIENPUyBleGNsdXNpdmVseSBpbiBvdXIgcHJvamVjdHMsIGJ1dCBJIGRvbid0IHRoaW5r
DQoJdGhhdCdzIGVhc3kgZm9yIFNwcmluZyB0byB1c2UgKGR1ZSB0byB0aGUgbGljZW5zaW5nKS4g
IEkgd291bGQgc2ltcGx5IGNvZGUNCgl0aGlzIGFjY29yZGluZyB0byBTcHJpbmcgbm9ybXMgdXNp
bmcgYW4gaW50ZXJmYWNlIGFuZCBhIGRlZmF1bHQgdmVyc2lvbg0KCXVzaW5nIENvbW1vbnMgRmls
ZVVwbG9hZC4gIExhdGVyLCBpZiBzb21lYm9keSB3YW50cyB0byBjcmVhdGUgYSBjb3MgdmVyc2lv
bg0KCXdlIGNhbiAoYnV0IHRvIGJlIGhvbmVzdCwgaWYgd2UgaGF2ZSBhIHdvcmtpbmcsIGludGVn
cmF0ZWQgc29sdXRpb24gSSdtIG5vdA0KCXN1cmUgdGhhdCBpcyBuZWNlc3NhcnkgLSBhdCBsZWFz
dCBub3QgaW4gdGhlIFNwcmluZyBmcmFtZXdvcmspLiAgQmFzaWNhbGx5LA0KCXByb3ZpZGUgaG9v
a3MgYW5kIGEgZGVmYXVsdCBpbXBsZW1lbnRhdGlvbiwgYW5kIGFsbG93IHVzZXJzIHRvIGFkb3B0
IGFzDQoJbmVjZXNzYXJ5Lg0KCQ0KCUluIG91ciBwcm9qZWN0IHdlIGhhZCBtb2RpZmllZCB0aGUg
QWJzdHJhY3RDb250cm9sbGVyIGFuZCBwdXQgdGhlIGNvZGUgaW50bw0KCWl0IHRvIGhhbmRsZSB0
aGUgbXVsdGlwYXJ0IHByb2Nlc3NpbmcsIHJldHVybmluZyBhIHdyYXBwZWQNCglIdHRwU2Vydmxl
dFJlcXVlc3QgdGhyb3VnaCB0aGUgaGFuZGxlcnMuICBUaGlzIGlzIHZlcnkgc2ltaWxpYXIgdG8g
SnVlcmdlbidzDQoJb3V0bGluZSAoaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9tYWlsYXJjaGl2ZS9t
ZXNzYWdlLnBocD9tc2dfaWQ9Mzg5MTI3OSkuDQoJDQoJU2luY2Ugd2UgYXJlIG1pZ3JhdGluZyB0
byB0aGUgY3VycmVudCBTcHJpbmcgY29kZWJhc2UsIEkgbmVlZCB0byBtb3ZlIG91cg0KCW11bHRp
cGFydCBoYW5kbGluZyBjb2RlLiAgVGhlIG1haW4gcXVlc3Rpb24gaXMgd2hldGhlciB3ZSBrZWVw
IGl0DQoJaW50ZXJuYWxseSwgb3IgcGxhY2UgaXQgaW50byBTcHJpbmcuICBJIHByb3Bvc2UgbW9k
aWZ5aW5nDQoJb3JnLnNwcmluZ2ZyYW1ld29yay53ZWIuc2VydmxldC5EaXNwYXRjaGVyU2Vydmxl
dCB0byBoYXZlIGENCgkiTXVsdGlwYXJ0UmVzb2x2ZXIiLiAgSW4gdGhlIERpc3BhdGNoZXJTZXJ2
bGV0LCB0aGUgcmVzb2x2ZXIgd291bGQgYmUgY2FsbGVkDQoJdG8gd3JhcCB0aGUgcmVxdWVzdCBp
biBkb1NlcnZpY2UgaW1tZWRpYXRlbHkgYmVmb3JlIGdldEhhbmRsZXIocmVxdWVzdCkgLQ0KCWN1
cnJlbnRseSBsaW5lIDM1MSwgYW5kIHRoZW4gY2FsbGVkIHRvIGRvIGFueSBjbGVhbnVwIGltbWVk
aWF0ZWx5IGJlZm9yZQ0KCWV4aXRpbmcgdGhlIGRvU2VydmljZSBtZXRob2QuDQoJDQoJSSBoYXZl
IGFib3V0IDIvMyBvZiB0aGUgY29kZSBhbHJlYWR5IHdyaXR0ZW4sIGFuZCBJIHdpbGwgYmUgd3Jp
dGluZyB0aGUgcmVzdA0KCWJldHdlZW4gbm93IGFuZCBNb25kYXkuICBEb2VzIHRoaXMgc3RyYXRl
Z3kgc291bmQgYXBwcm9wcmlhdGUgZm9yIFNwcmluZw0KCShtZWFuaW5nIHNob3VsZCBJIGNvbW1p
dCBpdCB0byB0aGUgU3ByaW5nIGNvZGViYXNlKSB3aGVuIGl0J3MgZmluaXNoZWQ/DQoJDQoJVHJl
dm9yIEQuIENvb2sNCglJbnRlcnByaXNlIFNvZnR3YXJlDQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgc2YubmV0
IGVtYWlsIGlzIHNwb25zb3JlZCBieTpUaGlua0dlZWsNCglXZWxjb21lIHRvIGdlZWsgaGVhdmVu
Lg0KCWh0dHA6Ly90aGlua2dlZWsuY29tL3NmDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxpbmcg
bGlzdA0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJ
aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3
b3JrLWRldmVsb3Blcg0KCQ0KDQo=

Re: [Springframework-developer] DispatcherServlet - no mapping found

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

Trevor,

On thinking it over further, making this an error was clearly a mistake.
Page not founds probably deserve their own logging category, so they could
be output completely separately from other messages.

Thoughts on this?

Regards,
Rod

----- Original Message ----- 
From: "Rod Johnson" <rod...@in...>
To: "Trevor Cook" <pr...@se...>; "Spring Developers"
<spr...@li...>
Sent: Saturday, September 27, 2003 10:18 PM
Subject: Re: [Springframework-developer] DispatcherServlet - no mapping
found


> Trevor,
>
> Sounds reasonable. I'm happy for you to change it.
>
> Regards,
> Rod
>
> ----- Original Message ----- 
> From: "Trevor Cook" <pr...@se...>
> To: "Spring Developers" <spr...@li...>
> Sent: Saturday, September 27, 2003 7:21 PM
> Subject: [Springframework-developer] DispatcherServlet - no mapping found
>
>
> > I have a bit of a problem with the DispatcherServlet's doService method,
> > specifically:
> >
> > if (mappedHandler == null || mappedHandler.getHandler() == null) {
> > // if we didn't find a handler
> > logger.error("No mapping for [" + WebUtils.getRequestUri(request) + "]
in
> > DispatcherServlet with name '" + getServletName() + "'");
> > response.sendError(HttpServletResponse.SC_NOT_FOUND);
> > return;
> > }
> >
> > I think the 404 is fine (I noticed the previous thread for multiaction
on
> > this - see
> http://sourceforge.net/mailarchive/message.php?msg_id=5986871).
> > My problem is "logger.error".  I have log4j send me anything above info
> for
> > my code, and anything error/fatal for Spring.  Because of this, I am
> > currently getting dozens of emails a day from spiders, spelling errors,
> and
> > 1 site that refuses to change a bad link on their page.   I considered
> just
> > changing my logging to only report fatal errors from Spring, but Spring
> > doesn't have any, and other errors it reports are important (like
> > transaction and configuration problems).  I'd like to change this from
> error
> > to warn.  "warn" is defined as:
> >
> > <quote>other runtime situations that are undesirable or unexpected, but
> not
> > necessarily "wrong".</quote> see
> > http://jakarta.apache.org/commons/logging/userguide.html
> >
> > I think that a 404 is not a desirable thing, but is fairly normal for a
> > webapp, so falls under the "not wrong" category.
> >
> > Let me know if there is general support for lowering the logging level
of
> > this message, or if I'm totally out to lunch.
> >
> > Trevor D. Cook
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>