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

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

Colin Sampaleanu wrote:

> 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.
> -----
>
>
Never mind. Maybe it didn't like the spelling error :-). When I changed 
the name to MatchAlways..., both files checked in...