Re: [Springframework-developer] AOP API changes

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

But that flag doesn't work the way somebody thought it does. If javac 
breaks in the middle of compiling 150 files, I think whoever set it that 
way thought it would still compile the other 149 files, but in fact it 
just gives up completely on the rest of the files. In my case for 
example, only 19 tests got compiled ok, then the build continued because 
of the flag, and all those (19) tests ran ok. Unless you actually look 
at the output during the compilation stage, you would never know that 
most of the files never got compiled or run.

I'll set the flag back the other way.


Alef Arendsen (JTeam) wrote:

>Probably from way back, when metadata tests where not compiling, might
>have been me committing it... Not sure...
>
>Anyway, as far as I'm concerned you can change it back to true
>
>Alef
>
>  
>
>>-----Oorspronkelijk bericht-----
>>Van: spr...@li... 
>>[mailto:spr...@li...]
>> Namens Colin Sampaleanu
>>Verzonden: Tuesday, November 11, 2003 10:57 PM
>>Aan: spr...@li...
>>Onderwerp: Re: [Springframework-developer] AOP API changes
>>
>>
>>Ok, w/regards to the compile failure not breaking the build, that's 
>>because build.xml sets failonerror="false" for the test classes.
>>        <javac destdir="${testbuild.dir}" target="1.3" 
>>debug="${debug}"
>>            deprecation="false" optimize="false" failonerror="false">
>>            <src path="${test.dir}"/>
>>            <classpath refid="master-classpath"/>
>>            <classpath location="${build.dir}"/>
>>        </javac>
>>I can not see a good use case for having it set this way. Can 
>>I change 
>>it to true (or take out that attr., which will default to true)?
>>
>>
>>
>>Colin Sampaleanu wrote:
>>
>>    
>>
>>>I get a javac build failure on the testsuite, as follows. What is
>>>really weird too, is that it doesn't break the build, ie 
>>>      
>>>
>>testing with 
>>    
>>
>>>the limited set of classes that has been produced, 
>>>      
>>>
>>commences after the 
>>    
>>
>>>javac failure:
>>>
>>>buildtests:
>>>   [mkdir] Created dir: D:\src\open\spring-colin\spring\.testclasses
>>>   [javac] Compiling 205 source files to
>>>D:\src\open\spring-colin\spring\.testc
>>>lasses
>>>   [javac] 
>>>D:\src\open\spring-colin\spring\test\org\springframework\context\sup
>>>port\StaticApplicationContextTestSuite.java:117: 
>>>org.springframework.context.sup
>>>port.StaticApplicationContextTestSuite.TestAutoProxyCreator is not 
>>>abstract and
>>>does not override abstract method 
>>>getInterceptorsAndAdvicesForBean(java.lang.Obj
>>>ect,java.lang.String) in 
>>>org.springframework.aop.framework.support.AbstractAutoP
>>>roxyCreator
>>>   [javac]     public static class TestAutoProxyCreator extends 
>>>AbstractAutoPro
>>>xyCreator {
>>>   [javac]                       ^
>>>   [javac] Note: Some input files use or override a deprecated API.
>>>   [javac] Note: Recompile with -deprecation for details.
>>>   [javac] 1 error
>>>   [javac] Compile failed; see the compiler error output 
>>>      
>>>
>>for details.
>>    
>>
>>>    [copy] Copying 19 files to 
>>>D:\src\open\spring-colin\spring\.testclasses
>>>
>>>tests:
>>>   [mkdir] Created dir: 
>>>      
>>>
>>D:\src\open\spring-colin\spring\junit-reports
>>    
>>
>>>   [junit] Running org.springframework.aop.framework.AopProxyTests
>>>  ...
>>>
>>>
>>>Kopylenko, Dmitry wrote:
>>>
>>>      
>>>
>>>>All,
>>>>
>>>>I've just commited some minor refactorings to the aop package:
>>>>- Refactored some names and javadocs to be compatable with new API
>>>>
>>>>Please re-sync.
>>>>
>>>>Regards,
>>>>Dmitriy.
>>>>
>>>>-----Original Message-----
>>>>From: Rod Johnson [mailto:rod...@in...] 
>>>>        
>>>>
>>Sent: Tuesday,
>>    
>>
>>>>November 11, 2003 1:34 PM
>>>>To: spr...@li...
>>>>Subject: [Springframework-developer] AOP API changes
>>>>Importance: High
>>>>
>>>>
>>>>All,
>>>>
>>>>I've just committed the current version of the AOP proposal (#2).
>>>>
>>>>All unit tests pass (naturally). However, there will be an 
>>>>        
>>>>
>>impact on
>>    
>>
>>>>code
>>>>using the AOP API. Interceptors are unaffected, unless 
>>>>        
>>>>
>>they relied on 
>>    
>>
>>>>the
>>>>AttributeRegistry, now removed. Pointcuts _are_ affected. 
>>>>        
>>>>
>>If you want 
>>    
>>
>>>>the
>>>>old Pointcut concept (Interceptor + when to apply it) subclass
>>>>StaticMethodMatcherPointcutAdvice and it should work the same. The
>>>>RegexpPointcut is also pretty similar, but does need a 
>>>>        
>>>>
>>reference to an
>>    
>>
>>>>Interceptor now. (A subclass that also implemented Advice could 
>>>>easily add
>>>>this.)
>>>>
>>>>The ProxyConfig API has changed significantly: code using this will
>>>>also be
>>>>broken.
>>>>
>>>>There's definitely scope for more abstract classes etc. to make the
>>>>API more
>>>>usable. However, it is definitely more powerful now.
>>>>
>>>>I'll be producing a migration guide from the old API.
>>>>
>>>>I need to refine the comments considerably. (Help welcome!) I also
>>>>need to
>>>>improve the tests for pointcut composition. Volunteers for 
>>>>        
>>>>
>>any of these
>>    
>>
>>>>tasks are welcome.
>>>>
>>>>Please update from CVS and check your code ASAP. With M3 
>>>>        
>>>>
>>coming up, 
>>    
>>
>>>>it's important that we are all sure everything works. AOP 
>>>>transactions shouldn't be affected, unless they did 
>>>>        
>>>>
>>something fancy 
>>    
>>
>>>>like provided their own MethodPointcut (now Pointcut).
>>>>
>>>>Regards,
>>>>Rod
>>>>  
>>>>        
>>>>