springframework-developer — Spring Framework developers list

Re: [Springframework-developer] new bean factory and application context features

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

Colin Sampaleanu wrote:

> Rod Johnson wrote:
>
>>> W/regards to redefining TransactionAttributeSourceEditor to allow for
>>> wildcards also in the classname, that's a useful feature, but the
>>> internal workings of the class would have to change. Right now, using a
>>> MethodMapTransactionAttributeSource, essentially all the methods of the
>>> specified classes get added to the transactional method map (if they
>>> match the method regex). So this approach wouldn't work for regexes at
>>> the class level. You'd probably have to do matches at runtime, with
>>> consequently slower performance (although I guess you could cache the
>>> hits and misses, to alleviate this, making the performance pretty well
>>> identical on second and subsequent calls to the same method). What do
>>> you think of this idea
>>>   
>>
>>
>> I prototyped such an approach a couple of months ago. The performance 
>> seemed
>> not too bad. I haven't committed it. However, maybe I should when I get
>> time, if people are interested.
>>  
>>
> I think this would be useful to some people (although the ability to 
> handle the 'all' case with another mechanism like the specialized 
> TransactionalAttributeSource would cover most of my needs)..
>
> If there are performance concerns, it could use a dual approach where 
> regexes on methods only (ie everything up to and including the class 
> name is specified) get handled as they do now, and other regexes get 
> handled with a runtime lookup with cache. My feeling is that the 
> runtime lookup with cache would perform well enough though. One 
> consideration is that the config semantics would change in terms of 
> typos. Right now MethodMapTransactionalAttributeSource gives you an 
> exception if you feed it a FQN which can't be resolved, or there are 
> no matching methods. I like the idea of detecting typos in this 
> fashion, if at all possible. Considering that your code may appear to 
> run fine even without the transaction, if you mess up the regex, I 
> think the error detection is valuable.  So if the code is extended, 
> maybe one way to do it would be to have two sets of properties, one 
> which behaves exactly like the present property (config time regexes 
> on methods only), and a new one which adds runtime regex matching on 
> the package and class portion as well.
>
> Regards,
> Colin

For the time being I have added a new class 
MatchAllwaysTransactionAttributeSource, which will always return the 
same TransactionAttribute (which may be set, otherwise it will default 
to PROPOGATION_REQUIRED).

I also tried to check in a unit test for it, but Eclipse barfed, then 
Tortoise as well on a re-attempt, with the error you get when there is a 
file in the attic wth the same name but a different case. This is 
definitely not the case, since this is a new file. Here's the error 
message from Tortoise. I don't know what to do since we don't have 
physical access to the repo to see what is going on.

-----
In D:\src\open\spring-colin\spring: cvs -q commit -m "add 
MatchAllwaysTransactionAttributeSource, which returns the same 
TransactionAttribute for all methods" 
test/org/springframework/transaction/interceptor/MatchAllwaysTransactionAttributeSourceTest.java
CVSROOT=:ext:co...@cv...:/cvsroot/springframework

cvs: hash.c:312: findnode: Assertion `key != ((void *)0)' failed.
cvs [server aborted]: received abort signal

Error, CVS operation failed

Tortoise Tip: This error can be caused because there used to be a file 
in the repository with a name differing only by case from the one you 
are adding. For example TEST.EXE rather than test.exe. To fix this go 
into the repository, or get your administrator to, and rename that file 
to have the same case. It will be in the Attic folder underneath the 
folder you are in. You will also need to get the local sandbox folder 
you are in out of CVS again, as it may have bogus entries to the 
misspelt filename.
-----

[Springframework-developer] Hibernate commit/rollback

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

VGhlcmUncyBhIGJ1ZyBlbnRyeSBvbiBTb3VyY2VGb3JnZSByZWdhcmRpbmcgSGliZXJuYXRlVHJh
bnNhY3Rpb25NYW5hZ2VyJ3MgY29tbWl0dGluZzoNCiANCklmIHRoZSBmbHVzaGluZyBvZiBjaGFu
Z2VzIGlzIGRlbGF5ZWQgKGkuZS4gSGliZXJuYXRlVGVtcGxhdGUgaXMgaW4gRkxVU0hfQVVUTyBt
b2RlLCBub3QgaW4gRkxVU0hfRUFHRVIpLCB0aGUgSGliZXJuYXRlIGNvbW1pdCBjYWxsIHdpbGwg
Zmlyc3QgaW1wbGljdGx5IGNhdXNlIGEgZmx1c2guIFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhhdCBm
bHVzaCBtaWdodCB0aHJvdyBhbiBleGNlcHRpb24gd2hpY2ggY2F1c2VzIEhpYmVybmF0ZSdzIGNv
bW1pdCBpbXBsZW1lbnRhdGlvbiB0byByZXR1cm4gd2l0aCB0aGUgZXhjZXB0aW9uLCB3aXRob3V0
IGEgY29tbWl0IGJ1dCB1bmZvcnR1bmF0ZWx5IGFsc28gd2l0aG91dCBhIHJvbGxiYWNrLg0KIA0K
VGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gb2YgSGliZXJuYXRlVHJhbnNhY3Rpb25NYW5hZ2Vy
IHdpbGwgbm90IGNhdXNlIGFuIGV4cGxpY2l0IHJvbGxiYWNrIGluIHRoYXQgY2FzZSwgYXMgaXQg
YXNzdW1lcyB0aGF0IHRoZSBjb21taXQgaGFzIGZhaWxlZCBhbmQgY2F1c2VkIGFuIGltcGxpY2l0
IHJvbGxiYWNrLiBJdCB0YWtlcyB0aGF0IGFzc3VtcHRpb24gZnJvbSBKVEE6IEFmdGVyIGEgZmFp
bGVkIGNvbW1pdCwgeW91IGRvbid0IGhhdmUgdG8gaW52b2tlIHJvbGxiYWNrIGFueW1vcmU7IHRo
ZSBmYWlsZWQgY29tbWl0IGhhcyBhbHJlYWR5IGNvbXBsZXRlZCB0aGUgdHJhbnNhY3Rpb24gd2l0
aCBhIHJvbGxiYWNrLg0KIA0KSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgYSBKREJDIGRyaXZl
ciBzaG91bGQgYmVoYXZlIHRoZSBzYW1lOiBJZiBhIGNvbW1pdCBoYXMgZmFpbGVkLCByb2xsYmFj
ayBkb2VzIG5vdCBoYXZlIHRvIGJlIGludm9rZWQgYW55bW9yZS4gV291bGQgaXQgYWN0dWFsbHkg
aHVydCBpZiBvbmUgc3RpbGwgaW52b2tlZCByb2xsYmFjaz8gV291bGQgdGhhdCBnZXQgaWdub3Jl
ZCB3aXRoIG1vc3QgZHJpdmVycywgb3Igd291bGQgaXQgY2F1c2UgeWV0IGFub3RoZXIgZXhjZXB0
aW9uLCBhIGxhICJ0cmFuc2FjdGlvbiBpcyBhbHJlYWR5IHJvbGxlZCBiYWNrIiBvciAibm8gdHJh
bnNhY3Rpb24gYW55bW9yZSI/DQogDQpJIGludGVuZCB0byBmaXggdGhlIEhpYmVybmF0ZSB0cmFu
c2FjdGlvbiBpc3N1ZSBsaWtlIHRoaXM6IEZpcnN0IGludm9rZSBmbHVzaCBtYW51YWxseSBhbmQg
dHJlYXQgaXQgbGlrZSBkYXRhIGFjY2VzcywgaS5lLiBqdXN0IGNvbW1pdCBpZiBpdCBzdWNjZWVk
ZWQsIGVsc2UgY2F1c2UgYW4gZXhwbGljaXQgcm9sbGJhY2suIEFyZW4ndCB0aGUgc2VtYW50aWNz
IG9mIEhpYmVybmF0ZSdzIGNvbW1pdCBtZXRob2QgYSBiaXQgb2RkPyBTaG91bGRuJ3QgaXQgY2F1
c2UgYSByb2xsYmFjayBpdHNlbGYgaWYgdGhlIGZsdXNoIGZhaWxlZD8NCiANCkknbSBub3Qgc3Vy
ZSBhYm91dCBKRE8gaW4gdGhhdCByZXNwZWN0LiBJdCB3aWxsIGFsc28gZmx1c2ggY2hhbmdlcyBh
dCBjb21taXQsIGFuZCB0aGVyZSBpcyBubyBjaGFuY2UgdG8gY2F1c2UgYW4gZXhwbGljaXQgZmx1
c2ggYmVmb3JlLiBUaGUgc3BlYyBhbmQgdGhlIGphdmFkb2NzIGFyZSB1bmNsZWFyIGFib3V0IHdo
ZXRoZXIgYSBmbHVzaGluZyBmYWlsdXJlIGNhdXNlcyBhIHJvbGxiYWNrIG9mIHRoZSBkYXRhc3Rv
cmUgdHJhbnNhY3Rpb24sIGJ1dCBJIGFzc3VtZSBzby4gQXQgbGVhc3QsIGl0IHNlZW1zIHRoYXQg
cm9sbGJhY2sgY2FuIGFuZCBzaG91bGQgbm90IGJlIGludm9rZWQgYWZ0ZXIgYW4gZXhjZXB0aW9u
IG9uIGNvbW1pdC4NCiANCkhhcyBhbnlvbmUgcHJhY3RpY2FsIGV4cGVyaWVuY2Ugd2l0aCB0aGVz
ZSBpc3N1ZXM/DQogDQpKdWVyZ2VuDQogDQogDQogDQogDQo=

[Springframework-developer] Expression language for use in ApplicationContext

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

Has an expression language available for use in the app context ever 
been considered? (as per email below)

-------- Original Message --------
Subject: 	Re: Spring XMLBeanFactory
Date: 	Wed, 15 Oct 2003 15:14:42 -0400
From: 	Colin Sampaleanu <col...@ex...>
To: 	Vladimir Blagojevic <vla...@cs...>
References: 	<Pin...@bl...>



It can't do this (to the best of my knowledge). There is an expression 
language available for use in the JSP tags, but this is not accessible 
in the contexts.

If there is enough of a use case for this it could certainly be done. 
One way would be to try leveraging the existing expression language 
code. I have no idea how easy this would be to do since I've actually 
never touched the web ui code. Another mechanism would be to bring in 
something like OGNL, which is quite powerful...

What is your usage scenario?


Vladimir Blagojevic wrote:

>Colin,
>
>Does XMLBeanFactory support reading property of bean X and assigning it
>to bean Y within declarative xml config file? I don't think so, but is
>there any chatter on the lists about that?
>
>Cheers
>
>  
>

Re: [Springframework-developer] new bean factory and application context features

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

I agree. Just because I don't think source level transaction 
declarations don't make sense (for me, or for the general usecases), 
doesn't mean there are not some usecases where they probably do make 
sense. On top of that, there are a lot of other things (besides 
transaction declarations) you can do with source level (or bytecode 
level, post-compilation) metadata...


Rod Johnson wrote:

>Spring doesn't try to tell people what to think. So we should aim to please
>both camps, and assume that users know best. (The customer is always right.)
>We already have a solution for the "externalization" camp--and we should
>improve it if we can. We now need to create a solution for the metadata
>camp.
>
>R
>
>----- Original Message ----- 
>From: "Kopylenko, Dmitry" <dko...@su...>
>To: "'Rod Johnson'" <rod...@in...>; "Kopylenko, Dmitry"
><dko...@su...>
>Cc: <spr...@li...>
>Sent: Wednesday, October 15, 2003 1:01 PM
>Subject: RE: [Springframework-developer] new bean factory and application
>context features
>
>
>I tend to think so too. However there going to be "two camps" of people -
>1)People who think source level metadata is a good thing
>
>2)People who think source level metadata is evil
>
>Dmitriy.
>
>-----Original Message-----
>From: Rod Johnson [mailto:rod...@in...]
>Sent: Wednesday, October 15, 2003 7:56 AM
>To: Kopylenko, Dmitry
>Cc: spr...@li...
>Subject: Re: [Springframework-developer] new bean factory and application
>context features
>
>
>I think .NET does this well. I think it can simplify typical usage, without
>sacrificing the ability to do more complex things externally.
>
>So I'm very keen to get it implemented--not too much work once we have
>usable attributes--and give it a spin.
>
>Regards,
>Rod
>
>----- Original Message ----- 
>From: "Kopylenko, Dmitry" <dko...@su...>
>To: "'Colin Sampaleanu'" <col...@ex...>
>Cc: "' '"jürgen höller [werk3AT]" ' '" <jue...@we...>;
><spr...@li...>
>Sent: Wednesday, October 15, 2003 12:53 PM
>Subject: RE: [Springframework-developer] new bean factory and application
>context features
>
>
>I guess it's -1 against the source level metadata use case. Well, since this
>is a brand new concept (for java at least) what are everyone's
>thoughts/feelings about it?
>
>Regards,
>Dmitriy.
>
>
>-----Original Message-----
>From: Colin Sampaleanu [mailt:col...@ex...]
>Sent: Tuesday, October 14, 2003 6:09 PM
>To: Kopylenko, Dmitry
>Cc: "'\"jürgen höller [werk3AT]\" '";
>'spr...@li... '
>Subject: Re: [Springframework-developer] new bean factory and application
>context features
>
>
>I suppose, although to tell you the truth I prefer to declare my
>trnasactions separately from the source. Putting them in the source couples
>things too closely for my taste, and makes management harder, given that I
>want to change things around for unit tests and the like.
>
>
>Kopylenko, Dmitry wrote:
>
>  
>
>>Colin,
>>
>>that will be possible when the metadata support and "magic"
>>TransactionAutoProxy creator will be in place ;-)
>>
>>Regards,
>>Dmitriy.
>>
>>-----Original Message-----
>>From: Colin Sampaleanu
>>To: "jürgen höller [werk3AT]"
>>Cc: spr...@li...
>>Sent: 10/14/2003 5:49 PM
>>Subject: Re: [Springframework-developer] new bean factory and
>>application context features
>>
>>jürgen höller [werk3AT] wrote:
>>
>>
>>
>>    
>>
>>>...
>>>
>>>This is a BeanPostProcessor bean that can be set up as follows to
>>>proxy
>>>
>>>
>>>      
>>>
>>the beans with the given names with the given interceptors. Note that
>>this is only one bean with proxy settings to define, although there
>>might be dozens of target beans with the same proxy behavior.
>>
>>
>>    
>>
>>><bean id="autoProxyCreator"
>>>
>>>
>>>      
>>>
>>class="org.springframework.aop.framework.support.AutoProxyCreator">
>>
>>
>>    
>>
>>><property
>>>
>>>
>>>      
>>>
>>name="beanNames"><value>myBean1,myBean2,myBean3</value></property>
>>
>>
>>    
>>
>>><property name="interceptors>
>>>  <list>
>>>    <ref bean="myInterceptor1"/>
>>>    <ref bean="myInterceptor2"/>
>>>  </list>
>>></property>
>>></bean>
>>>
>>>So setting up 10 transactional beans would just involve 1
>>>
>>>
>>>      
>>>
>>AutoProxyCreator and 1 transaction interceptor plus the 10 target beans
>>(12 beans in total), instead of 10 TransactionProxyFactoryBeans plus
>>the 10 target beans (20 beans in total). The transaction attributes
>>would be centralized though, in contrast to TransactionProxyFactoryBean
>>that keeps them local per individual proxy definition.
>>
>>
>>    
>>
>>>
>>>
>>>      
>>>
>>Hi Juergen,
>>
>>How do you see this being used (if at all) with the current
>>TransactionInterceptor, since its TransactionAttributeSource property
>>gets satisfied via a MethodMapTransactionAttributeSource instance
>>(which
>>
>>needs definitions in the format 'FQN.methodName'). While this works
>>fine
>>
>>when doing individual interceptors for use with ProxyFactoryBean, short
>>of adding new code I'm at a loss as to how I could use
>>TransactionInterceptor with BeanNameAutoProxy to do transactions on all
>>methods in all the beans I feed to the auto proxy.
>>
>>Just wondering if I missed something?
>>
>>Regards,
>>Colin
>>    
>>

Re: [Springframework-developer] new bean factory and application context features

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

Rod Johnson wrote:

>>W/regards to redefining TransactionAttributeSourceEditor to allow for
>>wildcards also in the classname, that's a useful feature, but the
>>internal workings of the class would have to change. Right now, using a
>>MethodMapTransactionAttributeSource, essentially all the methods of the
>>specified classes get added to the transactional method map (if they
>>match the method regex). So this approach wouldn't work for regexes at
>>the class level. You'd probably have to do matches at runtime, with
>>consequently slower performance (although I guess you could cache the
>>hits and misses, to alleviate this, making the performance pretty well
>>identical on second and subsequent calls to the same method). What do
>>you think of this idea
>>    
>>
>
>I prototyped such an approach a couple of months ago. The performance seemed
>not too bad. I haven't committed it. However, maybe I should when I get
>time, if people are interested.
>  
>
I think this would be useful to some people (although the ability to 
handle the 'all' case with another mechanism like the specialized 
TransactionalAttributeSource would cover most of my needs)..

If there are performance concerns, it could use a dual approach where 
regexes on methods only (ie everything up to and including the class 
name is specified) get handled as they do now, and other regexes get 
handled with a runtime lookup with cache. My feeling is that the runtime 
lookup with cache would perform well enough though. One consideration is 
that the config semantics would change in terms of typos. Right now 
MethodMapTransactionalAttributeSource gives you an exception if you feed 
it a FQN which can't be resolved, or there are no matching methods. I 
like the idea of detecting typos in this fashion, if at all possible. 
Considering that your code may appear to run fine even without the 
transaction, if you mess up the regex, I think the error detection is 
valuable.  So if the code is extended, maybe one way to do it would be 
to have two sets of properties, one which behaves exactly like the 
present property (config time regexes on methods only), and a new one 
which adds runtime regex matching on the package and class portion as well.

Regards,
Colin

Re: [Springframework-developer] new bean factory and application context features

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

> W/regards to redefining TransactionAttributeSourceEditor to allow for
> wildcards also in the classname, that's a useful feature, but the
> internal workings of the class would have to change. Right now, using a
> MethodMapTransactionAttributeSource, essentially all the methods of the
> specified classes get added to the transactional method map (if they
> match the method regex). So this approach wouldn't work for regexes at
> the class level. You'd probably have to do matches at runtime, with
> consequently slower performance (although I guess you could cache the
> hits and misses, to alleviate this, making the performance pretty well
> identical on second and subsequent calls to the same method). What do
> you think of this idea

I prototyped such an approach a couple of months ago. The performance seemed
not too bad. I haven't committed it. However, maybe I should when I get
time, if people are interested.

Re: [Springframework-developer] new bean factory and application context features

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

The specialized TransactionAttributeSource approach would work fine. 
This is obviously a trivial little class, but it would probably be worth 
adding it to Spring itself (with the transaction attribute as a 
parameter) so people could just create an instance as needed for this 
type of usecase.

W/regards to redefining TransactionAttributeSourceEditor to allow for 
wildcards also in the classname, that's a useful feature, but the 
internal workings of the class would have to change. Right now, using a 
MethodMapTransactionAttributeSource, essentially all the methods of the 
specified classes get added to the transactional method map (if they 
match the method regex). So this approach wouldn't work for regexes at 
the class level. You'd probably have to do matches at runtime, with 
consequently slower performance (although I guess you could cache the 
hits and misses, to alleviate this, making the performance pretty well 
identical on second and subsequent calls to the same method). What do 
you think of this idea?

Regards,
Colin

jürgen höller [werk3AT] wrote:

>Colin,
> 
>This is basically about a special TransactionAttributeSource implementation that would simply return the same TransactionAttribute for every method invocation. That should be easy enough to do:
> 
>public class MyTransactionAttributeSource implements TransactionAttributeSource {
>  public TransactionAttribute getTransactionAttribute(MethodInvocation invocation) {
>    return new DefaultTransactionAttribute(TransactionDefinition.PROPAGATION_REQUIRED);
>  }
>}
> 
>Simply define it as a bean then, linking it to TransactionInterceptor's transactionAttributeSource property via a bean reference.
> 
>As an alternative, we could refine the TransactionAttributeSourceEditor to allow for wildcards not only at the end of method names but already for the classname:
> 
>not only "mypackage.MyClass.myMethod=PROPAGATION_REQUIRED"
>and "mypackage.MyClass.my*=PROPAGATION_REQUIRED"
>but also (at least) "*=PROPAGATION_REQUIRED"
> 
>Juergen
> 
>
>	-----Ursprüngliche Nachricht----- 
>	Von: Colin Sampaleanu [mailto:col...@ex...] 
>	Gesendet: Mi 15.10.2003 03:31 
>	An: jürgen höller [werk3AT] 
>	Cc: spr...@li... 
>	Betreff: Re: [Springframework-developer] new bean factory and application context features
>	
>	
>
>	Sure, that would work of course. I was thinking more along the lines of
>	being able to handle at least the case of treating _everything_ with a
>	set of specified transaction semantics (e.g. PROPOGATION_REQUIRED),
>	without having to specify individual method matching regexes on each
>	class. There is a use case (especially when you don't care about
>	ultimate 'tuning' or when you want to defer that until later) for just
>	turning on transactions for everything. This seems even more relevant
>	when combine with BeanNameAutoProxy, so that you only have to add one
>	simple bean ref in one place, and you have transactionional wrapping.
>	
>	In my case for example, this would happilly cover the majority of my
>	transaction handling needs, with some fine tuning here and there (using
>	TransactionProxyFactoryBean) for maybe the 10-20% of the remaining cases...
>	
>	Regards,
>	Colin
>	
>	
>	
>	
>
>  
>

RE: [Springframework-developer] M2

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

Not crazy, otherwise I am too :)  Considering the maturity of the framework
(even before it became Spring) as well as the responsiveness/talent of the
core developers, we're treating Spring like internal code (not from an
ownership level but from a trust perspective).  Also, the previous "loose
freeze" for public api changes means that (for the most part) the core has
been pretty stable from an api-user's view for quite a while now.

We're using the CVS version for our live app, and we too have found it very
stable.  We've also done a significant amount of testing of our main app
(which in turn exercises a large portion of Spring).  I've found a few minor
bugs which have been fixed (by myself or others had already noticed them).
The only outstanding bug we've found which affects our code is the nested
bean problem (see
http://sourceforge.net/mailarchive/forum.php?thread_id=3212995&forum_id=2840
1) but we worked around that by temporarily removing the object equals from
a few objects (until we have time to look at/fix the bug). We're also using
"latest/greatest" features such as the multipart stuff and are now
implementing Juergen's new "multiple context/message files" (will eliminate
the huge ant task we have to assemble a single xml file from modularized
pieces).

Trevor


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Kopylenko, Dmitry
Sent: October 15, 2003 7:50 AM
To: 'Rod Johnson'; 'spr...@li...'
Subject: RE: [Springframework-developer] M2


Continuously testing CVS snapshots (actually we're developing phase 2 of our
project against latest CVS snapshots. Kinda crazy, isn't it? :-)
I can report it's VERY stable!!!

Regards,
Dmitriy.


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Wednesday, October 15, 2003 5:54 AM
To: spr...@li...
Subject: [Springframework-developer] M2


All,

Especially now that we're likely to get more downloads following the TSS
article, it's essential that M2 is stable.

Juergen suggested a few days ago that we all test a CVS snapshot in our
apps. I second this. Can I also suggest a lockdown on core functionality
until the M2 release (except for bug fixes and backward-compatible changes).
This doesn't apply to attributes or anything that's an evolving area.

Regards,
Rod




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net
hosts over 70,000 Open Source Projects. See the people who have HELPED US
provide better services: Click here: http://sourceforge.net/supporters.php
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.525 / Virus Database: 322 - Release Date: 09/10/2003

Re: [Springframework-developer] new bean factory and application context features

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

Spring doesn't try to tell people what to think. So we should aim to please
both camps, and assume that users know best. (The customer is always right.)
We already have a solution for the "externalization" camp--and we should
improve it if we can. We now need to create a solution for the metadata
camp.

R

----- Original Message ----- 
From: "Kopylenko, Dmitry" <dko...@su...>
To: "'Rod Johnson'" <rod...@in...>; "Kopylenko, Dmitry"
<dko...@su...>
Cc: <spr...@li...>
Sent: Wednesday, October 15, 2003 1:01 PM
Subject: RE: [Springframework-developer] new bean factory and application
context features


I tend to think so too. However there going to be "two camps" of people -
1)People who think source level metadata is a good thing

2)People who think source level metadata is evil

Dmitriy.

-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Wednesday, October 15, 2003 7:56 AM
To: Kopylenko, Dmitry
Cc: spr...@li...
Subject: Re: [Springframework-developer] new bean factory and application
context features


I think .NET does this well. I think it can simplify typical usage, without
sacrificing the ability to do more complex things externally.

So I'm very keen to get it implemented--not too much work once we have
usable attributes--and give it a spin.

Regards,
Rod

----- Original Message ----- 
From: "Kopylenko, Dmitry" <dko...@su...>
To: "'Colin Sampaleanu'" <col...@ex...>
Cc: "' '"jürgen höller [werk3AT]" ' '" <jue...@we...>;
<spr...@li...>
Sent: Wednesday, October 15, 2003 12:53 PM
Subject: RE: [Springframework-developer] new bean factory and application
context features


I guess it's -1 against the source level metadata use case. Well, since this
is a brand new concept (for java at least) what are everyone's
thoughts/feelings about it?

Regards,
Dmitriy.


-----Original Message-----
From: Colin Sampaleanu [mailt:col...@ex...]
Sent: Tuesday, October 14, 2003 6:09 PM
To: Kopylenko, Dmitry
Cc: "'\"jürgen höller [werk3AT]\" '";
'spr...@li... '
Subject: Re: [Springframework-developer] new bean factory and application
context features


I suppose, although to tell you the truth I prefer to declare my
trnasactions separately from the source. Putting them in the source couples
things too closely for my taste, and makes management harder, given that I
want to change things around for unit tests and the like.


Kopylenko, Dmitry wrote:

>Colin,
>
>that will be possible when the metadata support and "magic"
>TransactionAutoProxy creator will be in place ;-)
>
>Regards,
>Dmitriy.
>
>-----Original Message-----
>From: Colin Sampaleanu
>To: "jürgen höller [werk3AT]"
>Cc: spr...@li...
>Sent: 10/14/2003 5:49 PM
>Subject: Re: [Springframework-developer] new bean factory and
>application context features
>
>jürgen höller [werk3AT] wrote:
>
>
>
>>...
>>
>>This is a BeanPostProcessor bean that can be set up as follows to
>>proxy
>>
>>
>the beans with the given names with the given interceptors. Note that
>this is only one bean with proxy settings to define, although there
>might be dozens of target beans with the same proxy behavior.
>
>
>><bean id="autoProxyCreator"
>>
>>
>class="org.springframework.aop.framework.support.AutoProxyCreator">
>
>
>> <property
>>
>>
>name="beanNames"><value>myBean1,myBean2,myBean3</value></property>
>
>
>> <property name="interceptors>
>>   <list>
>>     <ref bean="myInterceptor1"/>
>>     <ref bean="myInterceptor2"/>
>>   </list>
>> </property>
>></bean>
>>
>>So setting up 10 transactional beans would just involve 1
>>
>>
>AutoProxyCreator and 1 transaction interceptor plus the 10 target beans
>(12 beans in total), instead of 10 TransactionProxyFactoryBeans plus
>the 10 target beans (20 beans in total). The transaction attributes
>would be centralized though, in contrast to TransactionProxyFactoryBean
>that keeps them local per individual proxy definition.
>
>
>>
>>
>>
>>
>Hi Juergen,
>
>How do you see this being used (if at all) with the current
>TransactionInterceptor, since its TransactionAttributeSource property
>gets satisfied via a MethodMapTransactionAttributeSource instance
>(which
>
>needs definitions in the format 'FQN.methodName'). While this works
>fine
>
>when doing individual interceptors for use with ProxyFactoryBean, short
>of adding new code I'm at a loss as to how I could use
>TransactionInterceptor with BeanNameAutoProxy to do transactions on all
>methods in all the beans I feed to the auto proxy.
>
>Just wondering if I missed something?
>
>Regards,
>Colin
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.
>SourceForge.net hosts over 70,000 Open Source Projects. See the people
>who have HELPED US provide better services: Click here:
>http://sourceforge.net/supporters.php
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net
hosts over 70,000 Open Source Projects. See the people who have HELPED US
provide better services: Click here: http://sourceforge.net/supporters.php
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] new bean factory and application context features

[Kopylenko, D. <dko...@ac...>]

I tend to think so too. However there going to be "two camps" of people =
-
1)People who think source level metadata is a good thing
=09
2)People who think source level metadata is evil

Dmitriy.

-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]=20
Sent: Wednesday, October 15, 2003 7:56 AM
To: Kopylenko, Dmitry
Cc: spr...@li...
Subject: Re: [Springframework-developer] new bean factory and =
application
context features


I think .NET does this well. I think it can simplify typical usage, =
without
sacrificing the ability to do more complex things externally.

So I'm very keen to get it implemented--not too much work once we have
usable attributes--and give it a spin.

Regards,
Rod

----- Original Message -----=20
From: "Kopylenko, Dmitry" <dko...@su...>
To: "'Colin Sampaleanu'" <col...@ex...>
Cc: "' '"j=FCrgen h=F6ller [werk3AT]" ' '" =
<jue...@we...>;
<spr...@li...>
Sent: Wednesday, October 15, 2003 12:53 PM
Subject: RE: [Springframework-developer] new bean factory and =
application
context features


I guess it's -1 against the source level metadata use case. Well, since =
this
is a brand new concept (for java at least) what are everyone's
thoughts/feelings about it?

Regards,
Dmitriy.


-----Original Message-----
From: Colin Sampaleanu [mailt:col...@ex...]
Sent: Tuesday, October 14, 2003 6:09 PM
To: Kopylenko, Dmitry
Cc: "'\"j=FCrgen h=F6ller [werk3AT]\" '";
'spr...@li... '
Subject: Re: [Springframework-developer] new bean factory and =
application
context features


I suppose, although to tell you the truth I prefer to declare my
trnasactions separately from the source. Putting them in the source =
couples
things too closely for my taste, and makes management harder, given =
that I
want to change things around for unit tests and the like.


Kopylenko, Dmitry wrote:

>Colin,
>
>that will be possible when the metadata support and "magic"=20
>TransactionAutoProxy creator will be in place ;-)
>
>Regards,
>Dmitriy.
>
>-----Original Message-----
>From: Colin Sampaleanu
>To: "j=FCrgen h=F6ller [werk3AT]"
>Cc: spr...@li...
>Sent: 10/14/2003 5:49 PM
>Subject: Re: [Springframework-developer] new bean factory and=20
>application context features
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>
>
>
>>...
>>
>>This is a BeanPostProcessor bean that can be set up as follows to=20
>>proxy
>>
>>
>the beans with the given names with the given interceptors. Note that=20
>this is only one bean with proxy settings to define, although there=20
>might be dozens of target beans with the same proxy behavior.
>
>
>><bean id=3D"autoProxyCreator"
>>
>>
>class=3D"org.springframework.aop.framework.support.AutoProxyCreator">
>
>
>> <property
>>
>>
>name=3D"beanNames"><value>myBean1,myBean2,myBean3</value></property>
>
>
>> <property name=3D"interceptors>
>>   <list>
>>     <ref bean=3D"myInterceptor1"/>
>>     <ref bean=3D"myInterceptor2"/>
>>   </list>
>> </property>
>></bean>
>>
>>So setting up 10 transactional beans would just involve 1
>>
>>
>AutoProxyCreator and 1 transaction interceptor plus the 10 target =
beans=20
>(12 beans in total), instead of 10 TransactionProxyFactoryBeans plus=20
>the 10 target beans (20 beans in total). The transaction attributes=20
>would be centralized though, in contrast to =
TransactionProxyFactoryBean=20
>that keeps them local per individual proxy definition.
>
>
>>
>>
>>
>>
>Hi Juergen,
>
>How do you see this being used (if at all) with the current=20
>TransactionInterceptor, since its TransactionAttributeSource property=20
>gets satisfied via a MethodMapTransactionAttributeSource instance=20
>(which
>
>needs definitions in the format 'FQN.methodName'). While this works=20
>fine
>
>when doing individual interceptors for use with ProxyFactoryBean, =
short=20
>of adding new code I'm at a loss as to how I could use=20
>TransactionInterceptor with BeanNameAutoProxy to do transactions on =
all=20
>methods in all the beans I feed to the auto proxy.
>
>Just wondering if I missed something?
>
>Regards,
>Colin
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.=20
>SourceForge.net hosts over 70,000 Open Source Projects. See the people =

>who have HELPED US provide better services: Click here:=20
>http://sourceforge.net/supporters.php
>_______________________________________________
>Springframework-developer mailing list=20
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. =
SourceForge.net
hosts over 70,000 Open Source Projects. See the people who have HELPED =
US
provide better services: Click here: =
http://sourceforge.net/supporters.php
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] new bean factory and application context features

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

I think .NET does this well. I think it can simplify typical usage, without
sacrificing the ability to do more complex things externally.

So I'm very keen to get it implemented--not too much work once we have
usable attributes--and give it a spin.

Regards,
Rod

----- Original Message ----- 
From: "Kopylenko, Dmitry" <dko...@su...>
To: "'Colin Sampaleanu'" <col...@ex...>
Cc: "' '"jürgen höller [werk3AT]" ' '" <jue...@we...>;
<spr...@li...>
Sent: Wednesday, October 15, 2003 12:53 PM
Subject: RE: [Springframework-developer] new bean factory and application
context features


I guess it's -1 against the source level metadata use case. Well, since this
is a brand new concept (for java at least) what are everyone's
thoughts/feelings about it?

Regards,
Dmitriy.


-----Original Message-----
From: Colin Sampaleanu [mailt:col...@ex...]
Sent: Tuesday, October 14, 2003 6:09 PM
To: Kopylenko, Dmitry
Cc: "'\"jürgen höller [werk3AT]\" '";
'spr...@li... '
Subject: Re: [Springframework-developer] new bean factory and application
context features


I suppose, although to tell you the truth I prefer to declare my
trnasactions separately from the source. Putting them in the source
couples things too closely for my taste, and makes management harder,
given that I want to change things around for unit tests and the like.


Kopylenko, Dmitry wrote:

>Colin,
>
>that will be possible when the metadata support and "magic"
>TransactionAutoProxy creator will be in place ;-)
>
>Regards,
>Dmitriy.
>
>-----Original Message-----
>From: Colin Sampaleanu
>To: "jürgen höller [werk3AT]"
>Cc: spr...@li...
>Sent: 10/14/2003 5:49 PM
>Subject: Re: [Springframework-developer] new bean factory and
>application context features
>
>jürgen höller [werk3AT] wrote:
>
>
>
>>...
>>
>>This is a BeanPostProcessor bean that can be set up as follows to
>>proxy
>>
>>
>the beans with the given names with the given interceptors. Note that
>this is only one bean with proxy settings to define, although there
>might be dozens of target beans with the same proxy behavior.
>
>
>><bean id="autoProxyCreator"
>>
>>
>class="org.springframework.aop.framework.support.AutoProxyCreator">
>
>
>> <property
>>
>>
>name="beanNames"><value>myBean1,myBean2,myBean3</value></property>
>
>
>> <property name="interceptors>
>>   <list>
>>     <ref bean="myInterceptor1"/>
>>     <ref bean="myInterceptor2"/>
>>   </list>
>> </property>
>></bean>
>>
>>So setting up 10 transactional beans would just involve 1
>>
>>
>AutoProxyCreator and 1 transaction interceptor plus the 10 target beans
>(12 beans in total), instead of 10 TransactionProxyFactoryBeans plus
>the 10 target beans (20 beans in total). The transaction attributes
>would be centralized though, in contrast to TransactionProxyFactoryBean
>that keeps them local per individual proxy definition.
>
>
>>
>>
>>
>>
>Hi Juergen,
>
>How do you see this being used (if at all) with the current
>TransactionInterceptor, since its TransactionAttributeSource property
>gets satisfied via a MethodMapTransactionAttributeSource instance (which
>
>needs definitions in the format 'FQN.methodName'). While this works
>fine
>
>when doing individual interceptors for use with ProxyFactoryBean, short
>of adding new code I'm at a loss as to how I could use
>TransactionInterceptor with BeanNameAutoProxy to do transactions on all
>methods in all the beans I feed to the auto proxy.
>
>Just wondering if I missed something?
>
>Regards,
>Colin
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.
>SourceForge.net hosts over 70,000 Open Source Projects. See the people
>who have HELPED US provide better services: Click here:
>http://sourceforge.net/supporters.php
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] new bean factory and application context features

[Kopylenko, D. <dko...@ac...>]

I guess it's -1 against the source level metadata use case. Well, since =
this
is a brand new concept (for java at least) what are everyone's
thoughts/feelings about it?

Regards,
Dmitriy.


-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...]=20
Sent: Tuesday, October 14, 2003 6:09 PM
To: Kopylenko, Dmitry
Cc: "'\"j=FCrgen h=F6ller [werk3AT]\" '";
'spr...@li... '
Subject: Re: [Springframework-developer] new bean factory and =
application
context features


I suppose, although to tell you the truth I prefer to declare my=20
trnasactions separately from the source. Putting them in the source=20
couples things too closely for my taste, and makes management harder,=20
given that I want to change things around for unit tests and the like.


Kopylenko, Dmitry wrote:

>Colin,
>
>that will be possible when the metadata support and "magic"=20
>TransactionAutoProxy creator will be in place ;-)
>
>Regards,
>Dmitriy.
>
>-----Original Message-----
>From: Colin Sampaleanu
>To: "j=FCrgen h=F6ller [werk3AT]"
>Cc: spr...@li...
>Sent: 10/14/2003 5:49 PM
>Subject: Re: [Springframework-developer] new bean factory and=20
>application context features
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>
> =20
>
>>...
>>
>>This is a BeanPostProcessor bean that can be set up as follows to=20
>>proxy
>>   =20
>>
>the beans with the given names with the given interceptors. Note that=20
>this is only one bean with proxy settings to define, although there=20
>might be dozens of target beans with the same proxy behavior.
> =20
>
>><bean id=3D"autoProxyCreator"
>>   =20
>>
>class=3D"org.springframework.aop.framework.support.AutoProxyCreator">
> =20
>
>> <property
>>   =20
>>
>name=3D"beanNames"><value>myBean1,myBean2,myBean3</value></property>
> =20
>
>> <property name=3D"interceptors>
>>   <list>
>>     <ref bean=3D"myInterceptor1"/>
>>     <ref bean=3D"myInterceptor2"/>
>>   </list>
>> </property>
>></bean>
>>
>>So setting up 10 transactional beans would just involve 1
>>   =20
>>
>AutoProxyCreator and 1 transaction interceptor plus the 10 target =
beans=20
>(12 beans in total), instead of 10 TransactionProxyFactoryBeans plus=20
>the 10 target beans (20 beans in total). The transaction attributes=20
>would be centralized though, in contrast to =
TransactionProxyFactoryBean=20
>that keeps them local per individual proxy definition.
> =20
>
>>=20
>>
>>   =20
>>
>Hi Juergen,
>
>How do you see this being used (if at all) with the current
>TransactionInterceptor, since its TransactionAttributeSource property=20
>gets satisfied via a MethodMapTransactionAttributeSource instance =
(which
>
>needs definitions in the format 'FQN.methodName'). While this works=20
>fine
>
>when doing individual interceptors for use with ProxyFactoryBean, =
short
>of adding new code I'm at a loss as to how I could use=20
>TransactionInterceptor with BeanNameAutoProxy to do transactions on =
all=20
>methods in all the beans I feed to the auto proxy.
>
>Just wondering if I missed something?
>
>Regards,
>Colin
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.=20
>SourceForge.net hosts over 70,000 Open Source Projects. See the people =

>who have HELPED US provide better services: Click here:=20
>http://sourceforge.net/supporters.php
>_______________________________________________
>Springframework-developer mailing list=20
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> =20
>

RE: [Springframework-developer] M2

[Kopylenko, D. <dko...@ac...>]

Continuously testing CVS snapshots (actually we're developing phase 2 of our
project against latest CVS snapshots. Kinda crazy, isn't it? :-)
I can report it's VERY stable!!!

Regards,
Dmitriy.
 

-----Original Message-----
From: Rod Johnson [mailto:rod...@in...] 
Sent: Wednesday, October 15, 2003 5:54 AM
To: spr...@li...
Subject: [Springframework-developer] M2


All,

Especially now that we're likely to get more downloads following the TSS
article, it's essential that M2 is stable.

Juergen suggested a few days ago that we all test a CVS snapshot in our
apps. I second this. Can I also suggest a lockdown on core functionality
until the M2 release (except for bug fixes and backward-compatible changes).
This doesn't apply to attributes or anything that's an evolving area.

Regards,
Rod




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net
hosts over 70,000 Open Source Projects. See the people who have HELPED US
provide better services: Click here: http://sourceforge.net/supporters.php
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Testing

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

> if someone better qualified doesn't put their hand up, I'd also be pleased
to
> try to take this on too.

Darren,

If you'd like to take ownership of this that would be great. I think a short
proposal (one page or so of text) would be great so that we can all review
the proposed strategy before getting down to implementation.

Regards,
Rod

[Springframework-developer] M2

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

All,

Especially now that we're likely to get more downloads following the TSS
article, it's essential that M2 is stable.

Juergen suggested a few days ago that we all test a CVS snapshot in our
apps. I second this. Can I also suggest a lockdown on core functionality
until the M2 release (except for bug fixes and backward-compatible changes).
This doesn't apply to attributes or anything that's an evolving area.

Regards,
Rod

Re: [Springframework-developer] new bean factory and application context features

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

Q29saW4sDQogDQpUaGlzIGlzIGJhc2ljYWxseSBhYm91dCBhIHNwZWNpYWwgVHJhbnNhY3Rpb25B
dHRyaWJ1dGVTb3VyY2UgaW1wbGVtZW50YXRpb24gdGhhdCB3b3VsZCBzaW1wbHkgcmV0dXJuIHRo
ZSBzYW1lIFRyYW5zYWN0aW9uQXR0cmlidXRlIGZvciBldmVyeSBtZXRob2QgaW52b2NhdGlvbi4g
VGhhdCBzaG91bGQgYmUgZWFzeSBlbm91Z2ggdG8gZG86DQogDQpwdWJsaWMgY2xhc3MgTXlUcmFu
c2FjdGlvbkF0dHJpYnV0ZVNvdXJjZSBpbXBsZW1lbnRzIFRyYW5zYWN0aW9uQXR0cmlidXRlU291
cmNlIHsNCiAgcHVibGljIFRyYW5zYWN0aW9uQXR0cmlidXRlIGdldFRyYW5zYWN0aW9uQXR0cmli
dXRlKE1ldGhvZEludm9jYXRpb24gaW52b2NhdGlvbikgew0KICAgIHJldHVybiBuZXcgRGVmYXVs
dFRyYW5zYWN0aW9uQXR0cmlidXRlKFRyYW5zYWN0aW9uRGVmaW5pdGlvbi5QUk9QQUdBVElPTl9S
RVFVSVJFRCk7DQogIH0NCn0NCiANClNpbXBseSBkZWZpbmUgaXQgYXMgYSBiZWFuIHRoZW4sIGxp
bmtpbmcgaXQgdG8gVHJhbnNhY3Rpb25JbnRlcmNlcHRvcidzIHRyYW5zYWN0aW9uQXR0cmlidXRl
U291cmNlIHByb3BlcnR5IHZpYSBhIGJlYW4gcmVmZXJlbmNlLg0KIA0KQXMgYW4gYWx0ZXJuYXRp
dmUsIHdlIGNvdWxkIHJlZmluZSB0aGUgVHJhbnNhY3Rpb25BdHRyaWJ1dGVTb3VyY2VFZGl0b3Ig
dG8gYWxsb3cgZm9yIHdpbGRjYXJkcyBub3Qgb25seSBhdCB0aGUgZW5kIG9mIG1ldGhvZCBuYW1l
cyBidXQgYWxyZWFkeSBmb3IgdGhlIGNsYXNzbmFtZToNCiANCm5vdCBvbmx5ICJteXBhY2thZ2Uu
TXlDbGFzcy5teU1ldGhvZD1QUk9QQUdBVElPTl9SRVFVSVJFRCINCmFuZCAibXlwYWNrYWdlLk15
Q2xhc3MubXkqPVBST1BBR0FUSU9OX1JFUVVJUkVEIg0KYnV0IGFsc28gKGF0IGxlYXN0KSAiKj1Q
Uk9QQUdBVElPTl9SRVFVSVJFRCINCiANCkp1ZXJnZW4NCiANCg0KCS0tLS0tVXJzcHLDvG5nbGlj
aGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBDb2xpbiBTYW1wYWxlYW51IFttYWlsdG86Y29saW5t
bDFAZXhpcy5jb21dIA0KCUdlc2VuZGV0OiBNaSAxNS4xMC4yMDAzIDAzOjMxIA0KCUFuOiBqw7xy
Z2VuIGjDtmxsZXIgW3dlcmszQVRdIA0KCUNjOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxp
c3RzLnNvdXJjZWZvcmdlLm5ldCANCglCZXRyZWZmOiBSZTogW1NwcmluZ2ZyYW1ld29yay1kZXZl
bG9wZXJdIG5ldyBiZWFuIGZhY3RvcnkgYW5kIGFwcGxpY2F0aW9uIGNvbnRleHQgZmVhdHVyZXMN
CgkNCgkNCg0KCVN1cmUsIHRoYXQgd291bGQgd29yayBvZiBjb3Vyc2UuIEkgd2FzIHRoaW5raW5n
IG1vcmUgYWxvbmcgdGhlIGxpbmVzIG9mDQoJYmVpbmcgYWJsZSB0byBoYW5kbGUgYXQgbGVhc3Qg
dGhlIGNhc2Ugb2YgdHJlYXRpbmcgX2V2ZXJ5dGhpbmdfIHdpdGggYQ0KCXNldCBvZiBzcGVjaWZp
ZWQgdHJhbnNhY3Rpb24gc2VtYW50aWNzIChlLmcuIFBST1BPR0FUSU9OX1JFUVVJUkVEKSwNCgl3
aXRob3V0IGhhdmluZyB0byBzcGVjaWZ5IGluZGl2aWR1YWwgbWV0aG9kIG1hdGNoaW5nIHJlZ2V4
ZXMgb24gZWFjaA0KCWNsYXNzLiBUaGVyZSBpcyBhIHVzZSBjYXNlIChlc3BlY2lhbGx5IHdoZW4g
eW91IGRvbid0IGNhcmUgYWJvdXQNCgl1bHRpbWF0ZSAndHVuaW5nJyBvciB3aGVuIHlvdSB3YW50
IHRvIGRlZmVyIHRoYXQgdW50aWwgbGF0ZXIpIGZvciBqdXN0DQoJdHVybmluZyBvbiB0cmFuc2Fj
dGlvbnMgZm9yIGV2ZXJ5dGhpbmcuIFRoaXMgc2VlbXMgZXZlbiBtb3JlIHJlbGV2YW50DQoJd2hl
biBjb21iaW5lIHdpdGggQmVhbk5hbWVBdXRvUHJveHksIHNvIHRoYXQgeW91IG9ubHkgaGF2ZSB0
byBhZGQgb25lDQoJc2ltcGxlIGJlYW4gcmVmIGluIG9uZSBwbGFjZSwgYW5kIHlvdSBoYXZlIHRy
YW5zYWN0aW9uaW9uYWwgd3JhcHBpbmcuDQoJDQoJSW4gbXkgY2FzZSBmb3IgZXhhbXBsZSwgdGhp
cyB3b3VsZCBoYXBwaWxseSBjb3ZlciB0aGUgbWFqb3JpdHkgb2YgbXkNCgl0cmFuc2FjdGlvbiBo
YW5kbGluZyBuZWVkcywgd2l0aCBzb21lIGZpbmUgdHVuaW5nIGhlcmUgYW5kIHRoZXJlICh1c2lu
Zw0KCVRyYW5zYWN0aW9uUHJveHlGYWN0b3J5QmVhbikgZm9yIG1heWJlIHRoZSAxMC0yMCUgb2Yg
dGhlIHJlbWFpbmluZyBjYXNlcy4uLg0KCQ0KCVJlZ2FyZHMsDQoJQ29saW4NCgkNCgkNCgkNCgkN
Cg0K

Re: [Springframework-developer] new bean factory and application context features

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

jürgen höller [werk3AT] wrote:

>Colin,
> 
>  
>
>>How do you see this being used (if at all) with the current
>>    
>>
>TransactionInterceptor, since its TransactionAttributeSource property
>gets satisfied via a MethodMapTransactionAttributeSource instance (which
>needs definitions in the format 'FQN.methodName'). While this works fine
>when doing individual interceptors for use with ProxyFactoryBean, short
>of adding new code I'm at a loss as to how I could use
>TransactionInterceptor with BeanNameAutoProxy to do transactions on all
>methods in all the beans I feed to the auto proxy.
>
>You need to use one shared TransactionInterceptor instance here, defining the attributes for the transactional methods of all the interfaces and classes involved:
><bean id="exampleTransactionInterceptor" class="org.springframework.transaction.interceptor.TransactionInterceptor">
>  <property name="transactionManager"><ref bean="myTransactionManager"/></property>
>  <property name="transactionAttributeSource">
>    <value>
>      example.ExampleBusinessInterface.exampleMethod=PROPAGATION_REQUIRED
>      example.ExampleBusinessInterface.anotherExampleMethod=PROPAGATION_REQUIRED
>      example.AnotherExampleBusinessInterface.exampleMethod=PROPAGATION_REQUIRED
>    </value>
>  </property>
></bean>
>
>That should work with multiple ProxyFactoryBeans that reference one single TransactionInterceptor, and thus also with BeanNameAutoProxyCreator.
> 
>  
>
Sure, that would work of course. I was thinking more along the lines of 
being able to handle at least the case of treating _everything_ with a 
set of specified transaction semantics (e.g. PROPOGATION_REQUIRED), 
without having to specify individual method matching regexes on each 
class. There is a use case (especially when you don't care about 
ultimate 'tuning' or when you want to defer that until later) for just 
turning on transactions for everything. This seems even more relevant 
when combine with BeanNameAutoProxy, so that you only have to add one 
simple bean ref in one place, and you have transactionional wrapping.

In my case for example, this would happilly cover the majority of my 
transaction handling needs, with some fine tuning here and there (using 
TransactionProxyFactoryBean) for maybe the 10-20% of the remaining cases...

Regards,
Colin

Re: [Springframework-developer] new bean factory and application context features

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

Q29saW4sDQogDQo+IEhvdyBkbyB5b3Ugc2VlIHRoaXMgYmVpbmcgdXNlZCAoaWYgYXQgYWxsKSB3
aXRoIHRoZSBjdXJyZW50DQpUcmFuc2FjdGlvbkludGVyY2VwdG9yLCBzaW5jZSBpdHMgVHJhbnNh
Y3Rpb25BdHRyaWJ1dGVTb3VyY2UgcHJvcGVydHkNCmdldHMgc2F0aXNmaWVkIHZpYSBhIE1ldGhv
ZE1hcFRyYW5zYWN0aW9uQXR0cmlidXRlU291cmNlIGluc3RhbmNlICh3aGljaA0KbmVlZHMgZGVm
aW5pdGlvbnMgaW4gdGhlIGZvcm1hdCAnRlFOLm1ldGhvZE5hbWUnKS4gV2hpbGUgdGhpcyB3b3Jr
cyBmaW5lDQp3aGVuIGRvaW5nIGluZGl2aWR1YWwgaW50ZXJjZXB0b3JzIGZvciB1c2Ugd2l0aCBQ
cm94eUZhY3RvcnlCZWFuLCBzaG9ydA0Kb2YgYWRkaW5nIG5ldyBjb2RlIEknbSBhdCBhIGxvc3Mg
YXMgdG8gaG93IEkgY291bGQgdXNlDQpUcmFuc2FjdGlvbkludGVyY2VwdG9yIHdpdGggQmVhbk5h
bWVBdXRvUHJveHkgdG8gZG8gdHJhbnNhY3Rpb25zIG9uIGFsbA0KbWV0aG9kcyBpbiBhbGwgdGhl
IGJlYW5zIEkgZmVlZCB0byB0aGUgYXV0byBwcm94eS4NCg0KWW91IG5lZWQgdG8gdXNlIG9uZSBz
aGFyZWQgVHJhbnNhY3Rpb25JbnRlcmNlcHRvciBpbnN0YW5jZSBoZXJlLCBkZWZpbmluZyB0aGUg
YXR0cmlidXRlcyBmb3IgdGhlIHRyYW5zYWN0aW9uYWwgbWV0aG9kcyBvZiBhbGwgdGhlIGludGVy
ZmFjZXMgYW5kIGNsYXNzZXMgaW52b2x2ZWQ6DQo8YmVhbiBpZD0iZXhhbXBsZVRyYW5zYWN0aW9u
SW50ZXJjZXB0b3IiIGNsYXNzPSJvcmcuc3ByaW5nZnJhbWV3b3JrLnRyYW5zYWN0aW9uLmludGVy
Y2VwdG9yLlRyYW5zYWN0aW9uSW50ZXJjZXB0b3IiPg0KICA8cHJvcGVydHkgbmFtZT0idHJhbnNh
Y3Rpb25NYW5hZ2VyIj48cmVmIGJlYW49Im15VHJhbnNhY3Rpb25NYW5hZ2VyIi8+PC9wcm9wZXJ0
eT4NCiAgPHByb3BlcnR5IG5hbWU9InRyYW5zYWN0aW9uQXR0cmlidXRlU291cmNlIj4NCiAgICA8
dmFsdWU+DQogICAgICBleGFtcGxlLkV4YW1wbGVCdXNpbmVzc0ludGVyZmFjZS5leGFtcGxlTWV0
aG9kPVBST1BBR0FUSU9OX1JFUVVJUkVEDQogICAgICBleGFtcGxlLkV4YW1wbGVCdXNpbmVzc0lu
dGVyZmFjZS5hbm90aGVyRXhhbXBsZU1ldGhvZD1QUk9QQUdBVElPTl9SRVFVSVJFRA0KICAgICAg
ZXhhbXBsZS5Bbm90aGVyRXhhbXBsZUJ1c2luZXNzSW50ZXJmYWNlLmV4YW1wbGVNZXRob2Q9UFJP
UEFHQVRJT05fUkVRVUlSRUQNCiAgICA8L3ZhbHVlPg0KICA8L3Byb3BlcnR5Pg0KPC9iZWFuPg0K
DQpUaGF0IHNob3VsZCB3b3JrIHdpdGggbXVsdGlwbGUgUHJveHlGYWN0b3J5QmVhbnMgdGhhdCBy
ZWZlcmVuY2Ugb25lIHNpbmdsZSBUcmFuc2FjdGlvbkludGVyY2VwdG9yLCBhbmQgdGh1cyBhbHNv
IHdpdGggQmVhbk5hbWVBdXRvUHJveHlDcmVhdG9yLg0KIA0KSnVlcmdlbg0KIA0K

Re: [Springframework-developer] new bean factory and application context features

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

I suppose, although to tell you the truth I prefer to declare my 
trnasactions separately from the source. Putting them in the source 
couples things too closely for my taste, and makes management harder, 
given that I want to change things around for unit tests and the like.


Kopylenko, Dmitry wrote:

>Colin,
>
>that will be possible when the metadata support and "magic"
>TransactionAutoProxy creator will be in place ;-)
>
>Regards,
>Dmitriy.
>
>-----Original Message-----
>From: Colin Sampaleanu
>To: "jürgen höller [werk3AT]"
>Cc: spr...@li...
>Sent: 10/14/2003 5:49 PM
>Subject: Re: [Springframework-developer] new bean factory and application
>context features
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>...
>>
>>This is a BeanPostProcessor bean that can be set up as follows to proxy
>>    
>>
>the beans with the given names with the given interceptors. Note that
>this is only one bean with proxy settings to define, although there
>might be dozens of target beans with the same proxy behavior.
>  
>
>><bean id="autoProxyCreator"
>>    
>>
>class="org.springframework.aop.framework.support.AutoProxyCreator">
>  
>
>> <property
>>    
>>
>name="beanNames"><value>myBean1,myBean2,myBean3</value></property>
>  
>
>> <property name="interceptors>
>>   <list>
>>     <ref bean="myInterceptor1"/>
>>     <ref bean="myInterceptor2"/>
>>   </list>
>> </property>
>></bean>
>>
>>So setting up 10 transactional beans would just involve 1
>>    
>>
>AutoProxyCreator and 1 transaction interceptor plus the 10 target beans
>(12 beans in total), instead of 10 TransactionProxyFactoryBeans plus the
>10 target beans (20 beans in total). The transaction attributes would be
>centralized though, in contrast to TransactionProxyFactoryBean that
>keeps them local per individual proxy definition.
>  
>
>> 
>>
>>    
>>
>Hi Juergen,
>
>How do you see this being used (if at all) with the current 
>TransactionInterceptor, since its TransactionAttributeSource property 
>gets satisfied via a MethodMapTransactionAttributeSource instance (which
>
>needs definitions in the format 'FQN.methodName'). While this works fine
>
>when doing individual interceptors for use with ProxyFactoryBean, short 
>of adding new code I'm at a loss as to how I could use 
>TransactionInterceptor with BeanNameAutoProxy to do transactions on all 
>methods in all the beans I feed to the auto proxy.
>
>Just wondering if I missed something?
>
>Regards,
>Colin
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.
>SourceForge.net hosts over 70,000 Open Source Projects.
>See the people who have HELPED US provide better services:
>Click here: http://sourceforge.net/supporters.php
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

RE: [Springframework-developer] new bean factory and application context features

[Kopylenko, D. <dko...@ac...>]

Colin,

that will be possible when the metadata support and "magic"
TransactionAutoProxy creator will be in place ;-)

Regards,
Dmitriy.

-----Original Message-----
From: Colin Sampaleanu
To: "j=C3=BCrgen h=C3=B6ller [werk3AT]"
Cc: spr...@li...
Sent: 10/14/2003 5:49 PM
Subject: Re: [Springframework-developer] new bean factory and =
application
context features

j=C3=BCrgen h=C3=B6ller [werk3AT] wrote:

>...
>
>This is a BeanPostProcessor bean that can be set up as follows to =
proxy
the beans with the given names with the given interceptors. Note that
this is only one bean with proxy settings to define, although there
might be dozens of target beans with the same proxy behavior.
>
><bean id=3D"autoProxyCreator"
class=3D"org.springframework.aop.framework.support.AutoProxyCreator">
>  <property
name=3D"beanNames"><value>myBean1,myBean2,myBean3</value></property>
>  <property name=3D"interceptors>
>    <list>
>      <ref bean=3D"myInterceptor1"/>
>      <ref bean=3D"myInterceptor2"/>
>    </list>
>  </property>
></bean>
>
>So setting up 10 transactional beans would just involve 1
AutoProxyCreator and 1 transaction interceptor plus the 10 target beans
(12 beans in total), instead of 10 TransactionProxyFactoryBeans plus =
the
10 target beans (20 beans in total). The transaction attributes would =
be
centralized though, in contrast to TransactionProxyFactoryBean that
keeps them local per individual proxy definition.
>=20
> =20
>
Hi Juergen,

How do you see this being used (if at all) with the current=20
TransactionInterceptor, since its TransactionAttributeSource property=20
gets satisfied via a MethodMapTransactionAttributeSource instance =
(which

needs definitions in the format 'FQN.methodName'). While this works =
fine

when doing individual interceptors for use with ProxyFactoryBean, short =

of adding new code I'm at a loss as to how I could use=20
TransactionInterceptor with BeanNameAutoProxy to do transactions on all =

methods in all the beans I feed to the auto proxy.

Just wondering if I missed something?

Regards,
Colin




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] new bean factory and application context features

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

jürgen höller [werk3AT] wrote:

>...
>
>This is a BeanPostProcessor bean that can be set up as follows to proxy the beans with the given names with the given interceptors. Note that this is only one bean with proxy settings to define, although there might be dozens of target beans with the same proxy behavior.
>
><bean id="autoProxyCreator" class="org.springframework.aop.framework.support.AutoProxyCreator">
>  <property name="beanNames"><value>myBean1,myBean2,myBean3</value></property>
>  <property name="interceptors>
>    <list>
>      <ref bean="myInterceptor1"/>
>      <ref bean="myInterceptor2"/>
>    </list>
>  </property>
></bean>
>
>So setting up 10 transactional beans would just involve 1 AutoProxyCreator and 1 transaction interceptor plus the 10 target beans (12 beans in total), instead of 10 TransactionProxyFactoryBeans plus the 10 target beans (20 beans in total). The transaction attributes would be centralized though, in contrast to TransactionProxyFactoryBean that keeps them local per individual proxy definition.
> 
>  
>
Hi Juergen,

How do you see this being used (if at all) with the current 
TransactionInterceptor, since its TransactionAttributeSource property 
gets satisfied via a MethodMapTransactionAttributeSource instance (which 
needs definitions in the format 'FQN.methodName'). While this works fine 
when doing individual interceptors for use with ProxyFactoryBean, short 
of adding new code I'm at a loss as to how I could use 
TransactionInterceptor with BeanNameAutoProxy to do transactions on all 
methods in all the beans I feed to the auto proxy.

Just wondering if I missed something?

Regards,
Colin

[Springframework-developer] Spring article on TSS

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

TSS have just published my article on Spring. Thanks to Alef, Dmitriy for
reviewing it and Colin for providing some material about Hibernate.

Regards,
Rod

RE: [Springframework-developer] Multipart File Handling

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

Not "just a distributed one", this team honestly is alot better than =
that (and you personally have put a ton into this thing, which I am =
indebted to you for).  At work I only get to choose the best and =
brightest within commuting distance, here we have a global pool.  Our =
other advantage is that nobody has to help (paycheque, etc.), so it's =
all pride and passion.  Plus no interruptions when somebody wants to =
borrow a stapler, etc. (fill in all your favorite Dilbert cartoons here =
:) ).

Anyway, the additional functionality is a bean which determines the =
"MaximumFileSize" based on the user who is logged in (using the standard =
"request.getUserPrincipal()") .  Our app has multiple roles, and we =
allow "small" upload sizes to the public, variable sizes to different =
business partners (for product lists, etc.), and unlimited sizes to the =
administrators (us and our clients).  It requires creating a =
"DiskFileUpload" for every multipart request, but it gives us a lot of =
flexibility.

Trevor


-----Original Message-----
From: j=C3=BCrgen h=C3=B6ller [werk3AT] =
[mailto:jue...@we...]
Sent: October 14, 2003 9:14 AM
To: Trevor Cook; Spring Developers
Subject: RE: [Springframework-developer] Multipart File Handling


The separating line in my original mail actually means about 2 hours =
inbetween... enough time to do intense code checks and some serious =
reconsideration. I still have to smile myself when I look at that again =
;-)

The arguments didn't flip completely BTW, just in terms of dismissing =
PropertyEditor as a whole: We don't use intermediate String =
representations via request.getParameter anymore, which was my main =
intent.

I'm glad that you're happy with it now. I'm too, actually! That's the =
great thing about working in a team, even if "just" a distributed one: =
Multiple points of view can create much better solutions than a single =
mind ever could.

Just out of curiosity: What additional functionality did you add to =
CommonsMultipartResolver?

Juergen


-----Original Message-----
From: Trevor Cook [mailto:pr...@se...]
Sent: Tuesday, October 14, 2003 3:06 PM
To: jrgen h ller [werk3AT]; Spring Developers
Subject: RE: [Springframework-developer] Multipart File Handling


It is interesting seeing your arguments flip 180 degrees in a few =
paragraphs, but you're not alone there.  I find the same thing, that =
talking helps me find my own solutions.

As far as the implementation goes, the changes are perfect.  It's a lot =
cleaner than my original version (no coupling with DispatcherServlet or =
property editors), but we still have the benefit of custom property =
handling.

I've migrated our project from the original multipart to the new =
version, and everything works great.  My code uses "standard" handling =
(byte[] and MultipartFile) as well as the custom property editors.  I've =
also subclassed the CommonsMultipartResolver to provide some additional =
functionality in our app, and that works perfect as well.

I think we have a winner :)

Trevor D. Cook


-----Original Message-----
From: jrgen h ller [werk3AT] [mailto:jue...@we...]
Sent: October 14, 2003 1:13 AM
To: jrgen h ller [werk3AT]; Trevor Cook; Spring Developers
Subject: Re: [Springframework-developer] Multipart File Handling


P.S.: Funny how the direction of an own argument can change in the =
course of a single email ;-) Of course, I was talking about =
PropertyEditor's setAsText (and the indirection with String values that =
match field names) in the first paragraph, and haven't had realized at =
that time that there was the completely different setValue option too...
=20
Juergen
=20

	-----Ursprngliche Nachricht-----=20
	Von: j rgen hller [werk3AT]=20
	Gesendet: Di 14.10.2003 01:26=20
	An: Trevor Cook; Spring Developers=20
	Cc:=20
	Betreff: Re: [Springframework-developer] Multipart File Handling
=09
=09

	Trevor,
=09
	Sorry if I've been a bit eager in terms of getting rid of the =
PropertyEditor stuff for multipart files. I strongly believe that the =
JavaBeans PropertyEditor is not appropriate for multipart files though, =
as it is about converting *String* parameters to other types. This is =
fine for standard ServletRequest parameters that come in as String =
values and need to be bound to arbitrary properties of command objects. =
Multipart files on the other hand are by their very nature complex =
objects; they do not have a natural String representation.
=09
	The previous mechanism of binding multipart files via PropertyEditor =
required MultipartHttpServletRequest's getParameter method to return the =
field name as value a la getParameter("myfield") -> "myfield", so that a =
PropertyEditor that can just see the value would be able to identify the =
field name and invoke MultipartHttpServletRequest's getFile("myfield") =
to return the MultipartFile instance. This *is* a workaround, as it is =
not at all natural to have getParameter return the field name as value =
in case of a multipart file.
=09
	ServletRequestDataBinder is not a bad place for binding multipart =
files, given that our MultipartHttpServletRequest is a generic interface =
that resides in the non-DispatcherServlet-specific web.multipart package =
now. I agree that it isn't generally preferable to hardcode binding =
options, but I've initially felt that there aren't any other meaningful =
conversions than a MultipartFile itself or a byte[] as value of a =
command bean property. Note that you can always override =
BaseCommandController's onBindAndValidate to perform *custom* binding.
=09
	-----
=09
	On second thought, I agree that a pluggable conversion mechanism is =
preferable. I've just reworked the multipart binding into a =
PropertyEditor mechanism again, but with a different implementation =
pattern: ServletRequestDataBinder simply binds the file map returned by =
MultipartHttpServletRequest.getFileMap as property values. This means =
that bean properties of type MultipartFile can be populated directly, =
without conversion. Other types go through the PropertyEditor mechanism, =
but via calling setValue(Object) instead of setAsText(String).
=09
	ByteArrayMultipartFileEditor and StringMultipartFileEditor implement =
setValue to transform the given MultipartFile instance into either a =
byte array or a String, the latter with configurable charset. Note than =
none of these needs a MultipartHttpServletRequest: They receive the =
MultipartFile instances bound as property values by =
ServletRequestDataBinder. Those two custom editors need to be registered =
with ServletRequestDataBinder via registerCustomEditor, preferably for =
specific fields to avoid conflicts with other fields of the type byte =
array or String.
=09
	I consider this a good solution, more flexible than the hardcoded =
binding, but also cleaner than the PropertyEditor indirection with =
String parameters. Thanks for pointing at the issue again! Overriding =
PropertyEditor's setValue is generally a nice way to convert from =
non-String values to the required type; I didn't think of it at first, =
and I had to tweak BeanWrapperImpl a bit to allow for it. I hope you =
like the current solution too; does it fulfil your requirements now?
=09
	Juergen
=09
=09
=09
	        -----Urspr ngliche Nachricht-----
	        Von: Trevor Cook [mailto:pr...@se...]
	        Gesendet: Mo 13.10.2003 22:22
	        An: jrgen h ller [werk3AT]; Spring Developers
	        Cc:
	        Betreff: RE: [Springframework-developer] Multipart File =
Handling
	      =20
	      =20
=09
	        <juergen>
	        Furthermore, I've dropped the previous PropertyEditors support, =
and the associated requirement for file parameters having to be =
available as normal parameters with the field name as value. That seemed =
like a workaround; instead, I've added explicit detection to =
ServletRequestDataBinder, which is now able to bind file parameters as =
MultipartFile or byte[], depending on the type of the target bean =
property. I've not reintroduced binding the original file name to a =
String property, as I can't see the value of that feature.
	        </juergen>
	      =20
	        No problem dropping the String <> filename, I wasn't sure if =
that would be useful or not.
	      =20
	        I do have a problem with dropping the PropertyEditors support, =
since in my mind it removes flexibility and consistency.
	      =20
	        Treating all the data (simple text fields or files) as =
parameters seems to make a lot more sense to me since you can then treat =
every piece of data the same (instead of having to handle parameters and =
files seperately).  If the implementation was a little clumsy I =
apologize, but the concept was not a workaround but a goal to allow the =
user to be able to treat all data in the same manner.
	      =20
	        The issue of flexibility is due to the "explicit detection to =
ServletRequestDataBinder".  In the previous implementation and the =
current one, files were automatically bound to an object based on the =
target properties type.  The difference was that you could override it =
with a custom property editor (in the BaseCommandController initBinder =
method, for example).  Under the current implementation, there is no way =
to override how the file is attached to the bean.  Do you (or anybody =
else) have any suggestions on how to override the default Spring =
handling (currently hard-coded in ServletRequestDataBinder), or any =
ideas of how to change the implementation to allow this custom handling?
	      =20
	        Trevor D. Cook
	      =20
	      =20
=09
	=
N=18HYXu=16w=1A+m>xZ=1AzMx'=17z{=08=1CB=105z??')rH?q=07z??J=07jgzx?G?q=07=
z?X?~zwX??=07jgz=20


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.525 / Virus Database: 322 - Release Date: 09/10/2003

RE: [Springframework-developer] Multipart File Handling

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

VGhlIHNlcGFyYXRpbmcgbGluZSBpbiBteSBvcmlnaW5hbCBtYWlsIGFjdHVhbGx5IG1lYW5zIGFi
b3V0IDIgaG91cnMgaW5iZXR3ZWVuLi4uIGVub3VnaCB0aW1lIHRvIGRvIGludGVuc2UgY29kZSBj
aGVja3MgYW5kIHNvbWUgc2VyaW91cyByZWNvbnNpZGVyYXRpb24uIEkgc3RpbGwgaGF2ZSB0byBz
bWlsZSBteXNlbGYgd2hlbiBJIGxvb2sgYXQgdGhhdCBhZ2FpbiA7LSkNCg0KVGhlIGFyZ3VtZW50
cyBkaWRuJ3QgZmxpcCBjb21wbGV0ZWx5IEJUVywganVzdCBpbiB0ZXJtcyBvZiBkaXNtaXNzaW5n
IFByb3BlcnR5RWRpdG9yIGFzIGEgd2hvbGU6IFdlIGRvbid0IHVzZSBpbnRlcm1lZGlhdGUgU3Ry
aW5nIHJlcHJlc2VudGF0aW9ucyB2aWEgcmVxdWVzdC5nZXRQYXJhbWV0ZXIgYW55bW9yZSwgd2hp
Y2ggd2FzIG15IG1haW4gaW50ZW50Lg0KDQpJJ20gZ2xhZCB0aGF0IHlvdSdyZSBoYXBweSB3aXRo
IGl0IG5vdy4gSSdtIHRvbywgYWN0dWFsbHkhIFRoYXQncyB0aGUgZ3JlYXQgdGhpbmcgYWJvdXQg
d29ya2luZyBpbiBhIHRlYW0sIGV2ZW4gaWYgImp1c3QiIGEgZGlzdHJpYnV0ZWQgb25lOiBNdWx0
aXBsZSBwb2ludHMgb2YgdmlldyBjYW4gY3JlYXRlIG11Y2ggYmV0dGVyIHNvbHV0aW9ucyB0aGFu
IGEgc2luZ2xlIG1pbmQgZXZlciBjb3VsZC4NCg0KSnVzdCBvdXQgb2YgY3VyaW9zaXR5OiBXaGF0
IGFkZGl0aW9uYWwgZnVuY3Rpb25hbGl0eSBkaWQgeW91IGFkZCB0byBDb21tb25zTXVsdGlwYXJ0
UmVzb2x2ZXI/DQoNCkp1ZXJnZW4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv
bTogVHJldm9yIENvb2sgW21haWx0bzpwcmlzZTAzQHNlbnRleC5uZXRdDQpTZW50OiBUdWVzZGF5
LCBPY3RvYmVyIDE0LCAyMDAzIDM6MDYgUE0NClRvOiBqw7xyZ2VuIGjDtmxsZXIgW3dlcmszQVRd
OyBTcHJpbmcgRGV2ZWxvcGVycw0KU3ViamVjdDogUkU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxv
cGVyXSBNdWx0aXBhcnQgRmlsZSBIYW5kbGluZw0KDQoNCkl0IGlzIGludGVyZXN0aW5nIHNlZWlu
ZyB5b3VyIGFyZ3VtZW50cyBmbGlwIDE4MCBkZWdyZWVzIGluIGEgZmV3IHBhcmFncmFwaHMsIGJ1
dCB5b3UncmUgbm90IGFsb25lIHRoZXJlLiAgSSBmaW5kIHRoZSBzYW1lIHRoaW5nLCB0aGF0IHRh
bGtpbmcgaGVscHMgbWUgZmluZCBteSBvd24gc29sdXRpb25zLg0KDQpBcyBmYXIgYXMgdGhlIGlt
cGxlbWVudGF0aW9uIGdvZXMsIHRoZSBjaGFuZ2VzIGFyZSBwZXJmZWN0LiAgSXQncyBhIGxvdCBj
bGVhbmVyIHRoYW4gbXkgb3JpZ2luYWwgdmVyc2lvbiAobm8gY291cGxpbmcgd2l0aCBEaXNwYXRj
aGVyU2VydmxldCBvciBwcm9wZXJ0eSBlZGl0b3JzKSwgYnV0IHdlIHN0aWxsIGhhdmUgdGhlIGJl
bmVmaXQgb2YgY3VzdG9tIHByb3BlcnR5IGhhbmRsaW5nLg0KDQpJJ3ZlIG1pZ3JhdGVkIG91ciBw
cm9qZWN0IGZyb20gdGhlIG9yaWdpbmFsIG11bHRpcGFydCB0byB0aGUgbmV3IHZlcnNpb24sIGFu
ZCBldmVyeXRoaW5nIHdvcmtzIGdyZWF0LiAgTXkgY29kZSB1c2VzICJzdGFuZGFyZCIgaGFuZGxp
bmcgKGJ5dGVbXSBhbmQgTXVsdGlwYXJ0RmlsZSkgYXMgd2VsbCBhcyB0aGUgY3VzdG9tIHByb3Bl
cnR5IGVkaXRvcnMuICBJJ3ZlIGFsc28gc3ViY2xhc3NlZCB0aGUgQ29tbW9uc011bHRpcGFydFJl
c29sdmVyIHRvIHByb3ZpZGUgc29tZSBhZGRpdGlvbmFsIGZ1bmN0aW9uYWxpdHkgaW4gb3VyIGFw
cCwgYW5kIHRoYXQgd29ya3MgcGVyZmVjdCBhcyB3ZWxsLg0KDQpJIHRoaW5rIHdlIGhhdmUgYSB3
aW5uZXIgOikNCg0KVHJldm9yIEQuIENvb2sNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KRnJvbTogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXSBbbWFpbHRvOmp1ZXJnZW4uaG9lbGxl
ckB3ZXJrM2F0LmNvbV0NClNlbnQ6IE9jdG9iZXIgMTQsIDIwMDMgMToxMyBBTQ0KVG86IGrDvHJn
ZW4gaMO2bGxlciBbd2VyazNBVF07IFRyZXZvciBDb29rOyBTcHJpbmcgRGV2ZWxvcGVycw0KU3Vi
amVjdDogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBNdWx0aXBhcnQgRmlsZSBIYW5k
bGluZw0KDQoNClAuUy46IEZ1bm55IGhvdyB0aGUgZGlyZWN0aW9uIG9mIGFuIG93biBhcmd1bWVu
dCBjYW4gY2hhbmdlIGluIHRoZSBjb3Vyc2Ugb2YgYSBzaW5nbGUgZW1haWwgOy0pIE9mIGNvdXJz
ZSwgSSB3YXMgdGFsa2luZyBhYm91dCBQcm9wZXJ0eUVkaXRvcidzIHNldEFzVGV4dCAoYW5kIHRo
ZSBpbmRpcmVjdGlvbiB3aXRoIFN0cmluZyB2YWx1ZXMgdGhhdCBtYXRjaCBmaWVsZCBuYW1lcykg
aW4gdGhlIGZpcnN0IHBhcmFncmFwaCwgYW5kIGhhdmVuJ3QgaGFkIHJlYWxpemVkIGF0IHRoYXQg
dGltZSB0aGF0IHRoZXJlIHdhcyB0aGUgY29tcGxldGVseSBkaWZmZXJlbnQgc2V0VmFsdWUgb3B0
aW9uIHRvby4uLg0KIA0KSnVlcmdlbg0KIA0KDQoJLS0tLS1VcnNwcm5nbGljaGUgTmFjaHJpY2h0
LS0tLS0gDQoJVm9uOiBqIHJnZW4gaGxsZXIgW3dlcmszQVRdIA0KCUdlc2VuZGV0OiBEaSAxNC4x
MC4yMDAzIDAxOjI2IA0KCUFuOiBUcmV2b3IgQ29vazsgU3ByaW5nIERldmVsb3BlcnMgDQoJQ2M6
IA0KCUJldHJlZmY6IFJlOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gTXVsdGlwYXJ0IEZp
bGUgSGFuZGxpbmcNCgkNCgkNCg0KCVRyZXZvciwNCgkNCglTb3JyeSBpZiBJJ3ZlIGJlZW4gYSBi
aXQgZWFnZXIgaW4gdGVybXMgb2YgZ2V0dGluZyByaWQgb2YgdGhlIFByb3BlcnR5RWRpdG9yIHN0
dWZmIGZvciBtdWx0aXBhcnQgZmlsZXMuIEkgc3Ryb25nbHkgYmVsaWV2ZSB0aGF0IHRoZSBKYXZh
QmVhbnMgUHJvcGVydHlFZGl0b3IgaXMgbm90IGFwcHJvcHJpYXRlIGZvciBtdWx0aXBhcnQgZmls
ZXMgdGhvdWdoLCBhcyBpdCBpcyBhYm91dCBjb252ZXJ0aW5nICpTdHJpbmcqIHBhcmFtZXRlcnMg
dG8gb3RoZXIgdHlwZXMuIFRoaXMgaXMgZmluZSBmb3Igc3RhbmRhcmQgU2VydmxldFJlcXVlc3Qg
cGFyYW1ldGVycyB0aGF0IGNvbWUgaW4gYXMgU3RyaW5nIHZhbHVlcyBhbmQgbmVlZCB0byBiZSBi
b3VuZCB0byBhcmJpdHJhcnkgcHJvcGVydGllcyBvZiBjb21tYW5kIG9iamVjdHMuIE11bHRpcGFy
dCBmaWxlcyBvbiB0aGUgb3RoZXIgaGFuZCBhcmUgYnkgdGhlaXIgdmVyeSBuYXR1cmUgY29tcGxl
eCBvYmplY3RzOyB0aGV5IGRvIG5vdCBoYXZlIGEgbmF0dXJhbCBTdHJpbmcgcmVwcmVzZW50YXRp
b24uDQoJDQoJVGhlIHByZXZpb3VzIG1lY2hhbmlzbSBvZiBiaW5kaW5nIG11bHRpcGFydCBmaWxl
cyB2aWEgUHJvcGVydHlFZGl0b3IgcmVxdWlyZWQgTXVsdGlwYXJ0SHR0cFNlcnZsZXRSZXF1ZXN0
J3MgZ2V0UGFyYW1ldGVyIG1ldGhvZCB0byByZXR1cm4gdGhlIGZpZWxkIG5hbWUgYXMgdmFsdWUg
YSBsYSBnZXRQYXJhbWV0ZXIoIm15ZmllbGQiKSAtPiAibXlmaWVsZCIsIHNvIHRoYXQgYSBQcm9w
ZXJ0eUVkaXRvciB0aGF0IGNhbiBqdXN0IHNlZSB0aGUgdmFsdWUgd291bGQgYmUgYWJsZSB0byBp
ZGVudGlmeSB0aGUgZmllbGQgbmFtZSBhbmQgaW52b2tlIE11bHRpcGFydEh0dHBTZXJ2bGV0UmVx
dWVzdCdzIGdldEZpbGUoIm15ZmllbGQiKSB0byByZXR1cm4gdGhlIE11bHRpcGFydEZpbGUgaW5z
dGFuY2UuIFRoaXMgKmlzKiBhIHdvcmthcm91bmQsIGFzIGl0IGlzIG5vdCBhdCBhbGwgbmF0dXJh
bCB0byBoYXZlIGdldFBhcmFtZXRlciByZXR1cm4gdGhlIGZpZWxkIG5hbWUgYXMgdmFsdWUgaW4g
Y2FzZSBvZiBhIG11bHRpcGFydCBmaWxlLg0KCQ0KCVNlcnZsZXRSZXF1ZXN0RGF0YUJpbmRlciBp
cyBub3QgYSBiYWQgcGxhY2UgZm9yIGJpbmRpbmcgbXVsdGlwYXJ0IGZpbGVzLCBnaXZlbiB0aGF0
IG91ciBNdWx0aXBhcnRIdHRwU2VydmxldFJlcXVlc3QgaXMgYSBnZW5lcmljIGludGVyZmFjZSB0
aGF0IHJlc2lkZXMgaW4gdGhlIG5vbi1EaXNwYXRjaGVyU2VydmxldC1zcGVjaWZpYyB3ZWIubXVs
dGlwYXJ0IHBhY2thZ2Ugbm93LiBJIGFncmVlIHRoYXQgaXQgaXNuJ3QgZ2VuZXJhbGx5IHByZWZl
cmFibGUgdG8gaGFyZGNvZGUgYmluZGluZyBvcHRpb25zLCBidXQgSSd2ZSBpbml0aWFsbHkgZmVs
dCB0aGF0IHRoZXJlIGFyZW4ndCBhbnkgb3RoZXIgbWVhbmluZ2Z1bCBjb252ZXJzaW9ucyB0aGFu
IGEgTXVsdGlwYXJ0RmlsZSBpdHNlbGYgb3IgYSBieXRlW10gYXMgdmFsdWUgb2YgYSBjb21tYW5k
IGJlYW4gcHJvcGVydHkuIE5vdGUgdGhhdCB5b3UgY2FuIGFsd2F5cyBvdmVycmlkZSBCYXNlQ29t
bWFuZENvbnRyb2xsZXIncyBvbkJpbmRBbmRWYWxpZGF0ZSB0byBwZXJmb3JtICpjdXN0b20qIGJp
bmRpbmcuDQoJDQoJLS0tLS0NCgkNCglPbiBzZWNvbmQgdGhvdWdodCwgSSBhZ3JlZSB0aGF0IGEg
cGx1Z2dhYmxlIGNvbnZlcnNpb24gbWVjaGFuaXNtIGlzIHByZWZlcmFibGUuIEkndmUganVzdCBy
ZXdvcmtlZCB0aGUgbXVsdGlwYXJ0IGJpbmRpbmcgaW50byBhIFByb3BlcnR5RWRpdG9yIG1lY2hh
bmlzbSBhZ2FpbiwgYnV0IHdpdGggYSBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb24gcGF0dGVybjog
U2VydmxldFJlcXVlc3REYXRhQmluZGVyIHNpbXBseSBiaW5kcyB0aGUgZmlsZSBtYXAgcmV0dXJu
ZWQgYnkgTXVsdGlwYXJ0SHR0cFNlcnZsZXRSZXF1ZXN0LmdldEZpbGVNYXAgYXMgcHJvcGVydHkg
dmFsdWVzLiBUaGlzIG1lYW5zIHRoYXQgYmVhbiBwcm9wZXJ0aWVzIG9mIHR5cGUgTXVsdGlwYXJ0
RmlsZSBjYW4gYmUgcG9wdWxhdGVkIGRpcmVjdGx5LCB3aXRob3V0IGNvbnZlcnNpb24uIE90aGVy
IHR5cGVzIGdvIHRocm91Z2ggdGhlIFByb3BlcnR5RWRpdG9yIG1lY2hhbmlzbSwgYnV0IHZpYSBj
YWxsaW5nIHNldFZhbHVlKE9iamVjdCkgaW5zdGVhZCBvZiBzZXRBc1RleHQoU3RyaW5nKS4NCgkN
CglCeXRlQXJyYXlNdWx0aXBhcnRGaWxlRWRpdG9yIGFuZCBTdHJpbmdNdWx0aXBhcnRGaWxlRWRp
dG9yIGltcGxlbWVudCBzZXRWYWx1ZSB0byB0cmFuc2Zvcm0gdGhlIGdpdmVuIE11bHRpcGFydEZp
bGUgaW5zdGFuY2UgaW50byBlaXRoZXIgYSBieXRlIGFycmF5IG9yIGEgU3RyaW5nLCB0aGUgbGF0
dGVyIHdpdGggY29uZmlndXJhYmxlIGNoYXJzZXQuIE5vdGUgdGhhbiBub25lIG9mIHRoZXNlIG5l
ZWRzIGEgTXVsdGlwYXJ0SHR0cFNlcnZsZXRSZXF1ZXN0OiBUaGV5IHJlY2VpdmUgdGhlIE11bHRp
cGFydEZpbGUgaW5zdGFuY2VzIGJvdW5kIGFzIHByb3BlcnR5IHZhbHVlcyBieSBTZXJ2bGV0UmVx
dWVzdERhdGFCaW5kZXIuIFRob3NlIHR3byBjdXN0b20gZWRpdG9ycyBuZWVkIHRvIGJlIHJlZ2lz
dGVyZWQgd2l0aCBTZXJ2bGV0UmVxdWVzdERhdGFCaW5kZXIgdmlhIHJlZ2lzdGVyQ3VzdG9tRWRp
dG9yLCBwcmVmZXJhYmx5IGZvciBzcGVjaWZpYyBmaWVsZHMgdG8gYXZvaWQgY29uZmxpY3RzIHdp
dGggb3RoZXIgZmllbGRzIG9mIHRoZSB0eXBlIGJ5dGUgYXJyYXkgb3IgU3RyaW5nLg0KCQ0KCUkg
Y29uc2lkZXIgdGhpcyBhIGdvb2Qgc29sdXRpb24sIG1vcmUgZmxleGlibGUgdGhhbiB0aGUgaGFy
ZGNvZGVkIGJpbmRpbmcsIGJ1dCBhbHNvIGNsZWFuZXIgdGhhbiB0aGUgUHJvcGVydHlFZGl0b3Ig
aW5kaXJlY3Rpb24gd2l0aCBTdHJpbmcgcGFyYW1ldGVycy4gVGhhbmtzIGZvciBwb2ludGluZyBh
dCB0aGUgaXNzdWUgYWdhaW4hIE92ZXJyaWRpbmcgUHJvcGVydHlFZGl0b3IncyBzZXRWYWx1ZSBp
cyBnZW5lcmFsbHkgYSBuaWNlIHdheSB0byBjb252ZXJ0IGZyb20gbm9uLVN0cmluZyB2YWx1ZXMg
dG8gdGhlIHJlcXVpcmVkIHR5cGU7IEkgZGlkbid0IHRoaW5rIG9mIGl0IGF0IGZpcnN0LCBhbmQg
SSBoYWQgdG8gdHdlYWsgQmVhbldyYXBwZXJJbXBsIGEgYml0IHRvIGFsbG93IGZvciBpdC4gSSBo
b3BlIHlvdSBsaWtlIHRoZSBjdXJyZW50IHNvbHV0aW9uIHRvbzsgZG9lcyBpdCBmdWxmaWwgeW91
ciByZXF1aXJlbWVudHMgbm93Pw0KCQ0KCUp1ZXJnZW4NCgkNCgkNCgkNCgkgICAgICAgIC0tLS0t
VXJzcHIgbmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KCSAgICAgICAgVm9uOiBUcmV2b3IgQ29vayBb
bWFpbHRvOnByaXNlMDNAc2VudGV4Lm5ldF0NCgkgICAgICAgIEdlc2VuZGV0OiBNbyAxMy4xMC4y
MDAzIDIyOjIyDQoJICAgICAgICBBbjoganJnZW4gaCBsbGVyIFt3ZXJrM0FUXTsgU3ByaW5nIERl
dmVsb3BlcnMNCgkgICAgICAgIENjOg0KCSAgICAgICAgQmV0cmVmZjogUkU6IFtTcHJpbmdmcmFt
ZXdvcmstZGV2ZWxvcGVyXSBNdWx0aXBhcnQgRmlsZSBIYW5kbGluZw0KCSAgICAgICANCgkgICAg
ICAgDQoJDQoJICAgICAgICA8anVlcmdlbj4NCgkgICAgICAgIEZ1cnRoZXJtb3JlLCBJJ3ZlIGRy
b3BwZWQgdGhlIHByZXZpb3VzIFByb3BlcnR5RWRpdG9ycyBzdXBwb3J0LCBhbmQgdGhlIGFzc29j
aWF0ZWQgcmVxdWlyZW1lbnQgZm9yIGZpbGUgcGFyYW1ldGVycyBoYXZpbmcgdG8gYmUgYXZhaWxh
YmxlIGFzIG5vcm1hbCBwYXJhbWV0ZXJzIHdpdGggdGhlIGZpZWxkIG5hbWUgYXMgdmFsdWUuIFRo
YXQgc2VlbWVkIGxpa2UgYSB3b3JrYXJvdW5kOyBpbnN0ZWFkLCBJJ3ZlIGFkZGVkIGV4cGxpY2l0
IGRldGVjdGlvbiB0byBTZXJ2bGV0UmVxdWVzdERhdGFCaW5kZXIsIHdoaWNoIGlzIG5vdyBhYmxl
IHRvIGJpbmQgZmlsZSBwYXJhbWV0ZXJzIGFzIE11bHRpcGFydEZpbGUgb3IgYnl0ZVtdLCBkZXBl
bmRpbmcgb24gdGhlIHR5cGUgb2YgdGhlIHRhcmdldCBiZWFuIHByb3BlcnR5LiBJJ3ZlIG5vdCBy
ZWludHJvZHVjZWQgYmluZGluZyB0aGUgb3JpZ2luYWwgZmlsZSBuYW1lIHRvIGEgU3RyaW5nIHBy
b3BlcnR5LCBhcyBJIGNhbid0IHNlZSB0aGUgdmFsdWUgb2YgdGhhdCBmZWF0dXJlLg0KCSAgICAg
ICAgPC9qdWVyZ2VuPg0KCSAgICAgICANCgkgICAgICAgIE5vIHByb2JsZW0gZHJvcHBpbmcgdGhl
IFN0cmluZyA8PiBmaWxlbmFtZSwgSSB3YXNuJ3Qgc3VyZSBpZiB0aGF0IHdvdWxkIGJlIHVzZWZ1
bCBvciBub3QuDQoJICAgICAgIA0KCSAgICAgICAgSSBkbyBoYXZlIGEgcHJvYmxlbSB3aXRoIGRy
b3BwaW5nIHRoZSBQcm9wZXJ0eUVkaXRvcnMgc3VwcG9ydCwgc2luY2UgaW4gbXkgbWluZCBpdCBy
ZW1vdmVzIGZsZXhpYmlsaXR5IGFuZCBjb25zaXN0ZW5jeS4NCgkgICAgICAgDQoJICAgICAgICBU
cmVhdGluZyBhbGwgdGhlIGRhdGEgKHNpbXBsZSB0ZXh0IGZpZWxkcyBvciBmaWxlcykgYXMgcGFy
YW1ldGVycyBzZWVtcyB0byBtYWtlIGEgbG90IG1vcmUgc2Vuc2UgdG8gbWUgc2luY2UgeW91IGNh
biB0aGVuIHRyZWF0IGV2ZXJ5IHBpZWNlIG9mIGRhdGEgdGhlIHNhbWUgKGluc3RlYWQgb2YgaGF2
aW5nIHRvIGhhbmRsZSBwYXJhbWV0ZXJzIGFuZCBmaWxlcyBzZXBlcmF0ZWx5KS4gIElmIHRoZSBp
bXBsZW1lbnRhdGlvbiB3YXMgYSBsaXR0bGUgY2x1bXN5IEkgYXBvbG9naXplLCBidXQgdGhlIGNv
bmNlcHQgd2FzIG5vdCBhIHdvcmthcm91bmQgYnV0IGEgZ29hbCB0byBhbGxvdyB0aGUgdXNlciB0
byBiZSBhYmxlIHRvIHRyZWF0IGFsbCBkYXRhIGluIHRoZSBzYW1lIG1hbm5lci4NCgkgICAgICAg
DQoJICAgICAgICBUaGUgaXNzdWUgb2YgZmxleGliaWxpdHkgaXMgZHVlIHRvIHRoZSAiZXhwbGlj
aXQgZGV0ZWN0aW9uIHRvIFNlcnZsZXRSZXF1ZXN0RGF0YUJpbmRlciIuICBJbiB0aGUgcHJldmlv
dXMgaW1wbGVtZW50YXRpb24gYW5kIHRoZSBjdXJyZW50IG9uZSwgZmlsZXMgd2VyZSBhdXRvbWF0
aWNhbGx5IGJvdW5kIHRvIGFuIG9iamVjdCBiYXNlZCBvbiB0aGUgdGFyZ2V0IHByb3BlcnRpZXMg
dHlwZS4gIFRoZSBkaWZmZXJlbmNlIHdhcyB0aGF0IHlvdSBjb3VsZCBvdmVycmlkZSBpdCB3aXRo
IGEgY3VzdG9tIHByb3BlcnR5IGVkaXRvciAoaW4gdGhlIEJhc2VDb21tYW5kQ29udHJvbGxlciBp
bml0QmluZGVyIG1ldGhvZCwgZm9yIGV4YW1wbGUpLiAgVW5kZXIgdGhlIGN1cnJlbnQgaW1wbGVt
ZW50YXRpb24sIHRoZXJlIGlzIG5vIHdheSB0byBvdmVycmlkZSBob3cgdGhlIGZpbGUgaXMgYXR0
YWNoZWQgdG8gdGhlIGJlYW4uICBEbyB5b3UgKG9yIGFueWJvZHkgZWxzZSkgaGF2ZSBhbnkgc3Vn
Z2VzdGlvbnMgb24gaG93IHRvIG92ZXJyaWRlIHRoZSBkZWZhdWx0IFNwcmluZyBoYW5kbGluZyAo
Y3VycmVudGx5IGhhcmQtY29kZWQgaW4gU2VydmxldFJlcXVlc3REYXRhQmluZGVyKSwgb3IgYW55
IGlkZWFzIG9mIGhvdyB0byBjaGFuZ2UgdGhlIGltcGxlbWVudGF0aW9uIHRvIGFsbG93IHRoaXMg
Y3VzdG9tIGhhbmRsaW5nPw0KCSAgICAgICANCgkgICAgICAgIFRyZXZvciBELiBDb29rDQoJICAg
ICAgIA0KCSAgICAgICANCgkNCglOGEhZWHUWdxorbT54Whp6TXgnF3p7CBxCEDV6Pz8nKXJIP3EH
ej8/SgdqZ3p4P0c/cQd6P1g/fnp3WD8/B2pneiANCg0KDQotLS0NCkluY29taW5nIG1haWwgaXMg
Y2VydGlmaWVkIFZpcnVzIEZyZWUuDQpDaGVja2VkIGJ5IEFWRyBhbnRpLXZpcnVzIHN5c3RlbSAo
aHR0cDovL3d3dy5ncmlzb2Z0LmNvbSkuDQpWZXJzaW9uOiA2LjAuNTI1IC8gVmlydXMgRGF0YWJh
c2U6IDMyMiAtIFJlbGVhc2UgRGF0ZTogMDkvMTAvMjAwMw0KDQo=

RE: [Springframework-developer] Multipart File Handling

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

It is interesting seeing your arguments flip 180 degrees in a few =
paragraphs, but you're not alone there.  I find the same thing, that =
talking helps me find my own solutions.

As far as the implementation goes, the changes are perfect.  It's a lot =
cleaner than my original version (no coupling with DispatcherServlet or =
property editors), but we still have the benefit of custom property =
handling.

I've migrated our project from the original multipart to the new =
version, and everything works great.  My code uses "standard" handling =
(byte[] and MultipartFile) as well as the custom property editors.  I've =
also subclassed the CommonsMultipartResolver to provide some additional =
functionality in our app, and that works perfect as well.

I think we have a winner :)

Trevor D. Cook


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


P.S.: Funny how the direction of an own argument can change in the =
course of a single email ;-) Of course, I was talking about =
PropertyEditor's setAsText (and the indirection with String values that =
match field names) in the first paragraph, and haven't had realized at =
that time that there was the completely different setValue option too...
=20
Juergen
=20

	-----Ursprngliche Nachricht-----=20
	Von: j rgen hller [werk3AT]=20
	Gesendet: Di 14.10.2003 01:26=20
	An: Trevor Cook; Spring Developers=20
	Cc:=20
	Betreff: Re: [Springframework-developer] Multipart File Handling
=09
=09

	Trevor,
=09
	Sorry if I've been a bit eager in terms of getting rid of the =
PropertyEditor stuff for multipart files. I strongly believe that the =
JavaBeans PropertyEditor is not appropriate for multipart files though, =
as it is about converting *String* parameters to other types. This is =
fine for standard ServletRequest parameters that come in as String =
values and need to be bound to arbitrary properties of command objects. =
Multipart files on the other hand are by their very nature complex =
objects; they do not have a natural String representation.
=09
	The previous mechanism of binding multipart files via PropertyEditor =
required MultipartHttpServletRequest's getParameter method to return the =
field name as value a la getParameter("myfield") -> "myfield", so that a =
PropertyEditor that can just see the value would be able to identify the =
field name and invoke MultipartHttpServletRequest's getFile("myfield") =
to return the MultipartFile instance. This *is* a workaround, as it is =
not at all natural to have getParameter return the field name as value =
in case of a multipart file.
=09
	ServletRequestDataBinder is not a bad place for binding multipart =
files, given that our MultipartHttpServletRequest is a generic interface =
that resides in the non-DispatcherServlet-specific web.multipart package =
now. I agree that it isn't generally preferable to hardcode binding =
options, but I've initially felt that there aren't any other meaningful =
conversions than a MultipartFile itself or a byte[] as value of a =
command bean property. Note that you can always override =
BaseCommandController's onBindAndValidate to perform *custom* binding.
=09
	-----
=09
	On second thought, I agree that a pluggable conversion mechanism is =
preferable. I've just reworked the multipart binding into a =
PropertyEditor mechanism again, but with a different implementation =
pattern: ServletRequestDataBinder simply binds the file map returned by =
MultipartHttpServletRequest.getFileMap as property values. This means =
that bean properties of type MultipartFile can be populated directly, =
without conversion. Other types go through the PropertyEditor mechanism, =
but via calling setValue(Object) instead of setAsText(String).
=09
	ByteArrayMultipartFileEditor and StringMultipartFileEditor implement =
setValue to transform the given MultipartFile instance into either a =
byte array or a String, the latter with configurable charset. Note than =
none of these needs a MultipartHttpServletRequest: They receive the =
MultipartFile instances bound as property values by =
ServletRequestDataBinder. Those two custom editors need to be registered =
with ServletRequestDataBinder via registerCustomEditor, preferably for =
specific fields to avoid conflicts with other fields of the type byte =
array or String.
=09
	I consider this a good solution, more flexible than the hardcoded =
binding, but also cleaner than the PropertyEditor indirection with =
String parameters. Thanks for pointing at the issue again! Overriding =
PropertyEditor's setValue is generally a nice way to convert from =
non-String values to the required type; I didn't think of it at first, =
and I had to tweak BeanWrapperImpl a bit to allow for it. I hope you =
like the current solution too; does it fulfil your requirements now?
=09
	Juergen
=09
=09
=09
	        -----Urspr ngliche Nachricht-----
	        Von: Trevor Cook [mailto:pr...@se...]
	        Gesendet: Mo 13.10.2003 22:22
	        An: jrgen h ller [werk3AT]; Spring Developers
	        Cc:
	        Betreff: RE: [Springframework-developer] Multipart File =
Handling
	      =20
	      =20
=09
	        <juergen>
	        Furthermore, I've dropped the previous PropertyEditors support, =
and the associated requirement for file parameters having to be =
available as normal parameters with the field name as value. That seemed =
like a workaround; instead, I've added explicit detection to =
ServletRequestDataBinder, which is now able to bind file parameters as =
MultipartFile or byte[], depending on the type of the target bean =
property. I've not reintroduced binding the original file name to a =
String property, as I can't see the value of that feature.
	        </juergen>
	      =20
	        No problem dropping the String <> filename, I wasn't sure if =
that would be useful or not.
	      =20
	        I do have a problem with dropping the PropertyEditors support, =
since in my mind it removes flexibility and consistency.
	      =20
	        Treating all the data (simple text fields or files) as =
parameters seems to make a lot more sense to me since you can then treat =
every piece of data the same (instead of having to handle parameters and =
files seperately).  If the implementation was a little clumsy I =
apologize, but the concept was not a workaround but a goal to allow the =
user to be able to treat all data in the same manner.
	      =20
	        The issue of flexibility is due to the "explicit detection to =
ServletRequestDataBinder".  In the previous implementation and the =
current one, files were automatically bound to an object based on the =
target properties type.  The difference was that you could override it =
with a custom property editor (in the BaseCommandController initBinder =
method, for example).  Under the current implementation, there is no way =
to override how the file is attached to the bean.  Do you (or anybody =
else) have any suggestions on how to override the default Spring =
handling (currently hard-coded in ServletRequestDataBinder), or any =
ideas of how to change the implementation to allow this custom handling?
	      =20
	        Trevor D. Cook
	      =20
	      =20
=09
	=
N=18HYXu=16w=1A+m>xZ=1AzMx'=17z{=08=1CB=105z??')rH?q=07z??J=07jgzx?G?q=07=
z?X?~zwX??=07jgz=20


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.525 / Virus Database: 322 - Release Date: 09/10/2003