springframework-developer — Spring Framework developers list

RE: [Springframework-developer] AOP API changes

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

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
> >>   
> >
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest 
> developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, 
> and more! http://www.apachecon.com/ 
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] AOP API changes

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

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
>>   
>

Re: [Springframework-developer] AOP API changes

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

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
>  
>

[Springframework-developer] FW: Eclipse Plugin-Based Applications and J2EE Components

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

Provides some interesting reading w/regards to using a modified version 
of the Eclipse runtime  for component based development:
    http://www.choicemaker.com/EclipsePlugins.htm

The Eclipse runtime is interesting (to me anyways), because it deals 
with some issues such as versioning, updates, and extensions, that are 
left out of most frameworks.

A few of the basic concepts in the HiveMind project actually appear to 
be taken straight from the Eclipse model, with others (all the AOP stuff 
and some configuration mechanisms) being totally new.

Regards,
Colin

RE: [Springframework-developer] AOP API changes

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

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




-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest developments in
Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more!
http://www.apachecon.com/ _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] About MVC

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

On Tuesday 11 November 2003 12:53, William G. Thompson, Jr. wrote:
> You seem to be describing a Portal which has two parts

--snip--

> Each Portlet is in essence a separate web app and could use the standard
> Spring MVC model with some slight modifications

If the app really is a portal, then this is valid, but my impression was the 
OP was talking about instances where controllers have to return model data 
that is peripheral to the user's request, but still very definitely an 
integral part of the one web application.

For example, a controller may process a search request and return a model 
comprising a List of SearchResult objects.  The view still needs to be 
built with (for example) a left-side navigator that depends on database 
content.  Should every controller within the application be made aware of 
how to retreive this part of the model?

If I understand correctly, that's the sort of scenario being described..?

Best wishes,
-- 

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

[Springframework-developer] AOP API changes

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

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

RE: [Springframework-developer] Revised AOP API proposal

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

Just F.Y.I.

 jboss-aop uses "Advisor" abstraction, e.g. InstanceAdvisor, ClassAdvisor,
ProxyAdvisor

Regards,
Dmitriy.

-----Original Message-----
From: Rod Johnson [mailto:rod...@in...] 
Sent: Tuesday, November 11, 2003 12:36 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Revised AOP API proposal


Renaud,

I guess you're right regarding what "advice" should be in AOP. AspectJ is
not the cleanest implementation around.

However, for the moment, I'm going to check in a version with "Advice" as
discussed. (I'm just verifying that the whole test suite runs right now.)

It's fairly easy to refactor to change if necessary later, so we can
continue to discuss this.

I'm not crazy about Advisor. And I suspect that Advice may be clearer to
many, like I, who think of AspectJ concepts.

But let's continue to discuss it, and I'm sure it will be helpful to have
some code out there that implements the basic concepts.

Regarding perInstance, Spring supports this via the BeanFactory's
"singleton/prototype" option or programmatic creation (used a shared
interceptor if you want to). However, I can see that it arguably belongs on
the AOP API.

Spring could probably use a perInstance flag to check that the user has
configured the object correctly, rather than drive the configuration.
However, I'll also leave this out for now pending further discussion.

Regards,
Rod

----- Original Message ----- 
From: "renaud" <re...@ao...>
To: <spr...@li...>
Cc: "'Colin Sampaleanu'" <col...@ex...>; "'Bob Lee'"
<cra...@cr...>
Sent: Tuesday, November 11, 2003 3:23 PM
Subject: RE: [Springframework-developer] Revised AOP API proposal


>
>
> Yes. Actually I do not like the fact that in AspectJ an advice in 
> defined regarding a pointcut. I've found it very unclear what is 
> exactly the advice in the AspectJ semantics.
>
> <AspectJDoc>
> A join point is a well-defined point in the program flow. Pointcuts 
> select certain join points and values at those points. Advice defines 
> code that
is
> executed when a pointcut is reached. These are, then, the dynamic 
> parts of AspectJ. </AspectJDoc>
>
> By reading this, you can really think that the advice and the pointcut 
> are orthogonal and defined independently. Indeed, it seems not 
> flexible at all

> to define at the same place the code to be executed and where it is 
> executed.
>
> But, later in the same doc:
>
> <AspectJDoc>
> Pointcuts are used in the definition of advice.
> </AspectJDoc>
>
> To me it is confusing. Moreover, lots of work on AOP have pointed out 
> the benefits of having independent structures for the both. To me 
> AspectJ
misses
> something here: the ability to define independent (unlocated) advice 
> --
like
> an interceptor does.
>
> So it seems to me that the concept of Advisor helps here. It sounds 
> like saying "we advise some code" and "we do not use advice concept
specifically
> because it is unclear and, btw, we use interceptors which are 
> independent structures - more flexible than the advice constructs in 
> AspectJ".
>
> Regards,
> Renaud.
>
> ---
> Renaud Pawlak
> Software Engineering Department
> Rensselaer at Hartford
> 275 Windsor St, Hartford, CT 06120-2991
> Work: 860-548-5358 Mobile: 860-748-5527
> Emails: pa...@rh..., re...@ao...
> WWW: http://www.lifl.fr/~pawlak
>
>
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]
> >  On Behalf Of Kopylenko, Dmitry
> > Sent: Tuesday, November 11, 2003 9:52 AM
> > To: 'renaud'; 'spr...@li...'
> > Cc: 'Colin Sampaleanu'; 'Bob Lee'
> > Subject: RE: [Springframework-developer] Revised AOP API proposal
> >
> >
> > Advisor does not fall under "standard" AOP concepts as opposed to 
> > Advice, but I like the name better.
> >
> > My 2c.
> >
> > Dmitriy.
> >
> > -----Original Message-----
> > From: renaud [mailto:re...@ao...]
> > Sent: Tuesday, November 11, 2003 9:19 AM
> > To: spr...@li...
> > Cc: 'Kopylenko, Dmitry'; 'Colin Sampaleanu'; 'Bob Lee'
> > Subject: RE: [Springframework-developer] Revised AOP API proposal
> >
> >
> >
> > Hi all,
> >
> > I have been working a lot these last days on a JAC refactoring in 
> > order that our two frameworks implement a simplar API (well, as much 
> > as possible). Morever this allows me to detect weaknesses of the 
> > proposed API.
> >
> > Rod, when do you plan to consider the API definitively fixed (so 
> > that I kown until when I can work on it)?
> >
> > The main problem I see for now on is about the per-instance 
> > property. In AOP, you are supposed to be able to precise if the 
> > aspect will be applied globally, or on a per-instance basis. For 
> > instance, you may want an advice to install the same interceptor for 
> > your whole pointcut, or seamlessly create a different instance for 
> > each instance cut by the pointcut.
> >
> > This is not difficult to solve. We can propose a method
> > isPerInstance() on the Advice.
> >
> > By the way, by thinking a lot about this "Advice" interface, it 
> > turned out that the concept of advice as defined in AOP (I means 
> > theorical AOP) does not includes the pointcut. However, in AspectJ, 
> > it actually corresponds to an actual construct. So, I figured out 
> > that the best way to solve the issue was to call this construct an 
> > "Advisor". Note that it has the advantage to solve the problem of 
> > the advice plural ("Advice[] getAdvice()" is not very cool).
> >
> > So my intermediate proposal would be:
> >
> > public interface Advisor {
> >     boolean isPerInstance();
> > }
> >
> > And rename
> > InterceptionAdvice into InterceptionAdvisor IntroductionAdvice into 
> > IntroductionAdvisor
> >
> > In the aspect, you will also have a getAdvisors method instead of a 
> > getAdvice method.
> >
> > As you can see, it is not a big deal of a change at all.
> >
> > Best,
> > Renaud.
> >
> > ---
> > Renaud Pawlak
> > Software Engineering Department
> > Rensselaer at Hartford
> > 275 Windsor St, Hartford, CT 06120-2991
> > Work: 860-548-5358 Mobile: 860-748-5527
> > Emails: pa...@rh..., re...@ao...
> > WWW: http://www.lifl.fr/~pawlak
> >
> >
> > > -----Original Message-----
> > > From: spr...@li...
> > > [mailto:spr...@li...]
> > >  On Behalf Of Rod Johnson
> > > Sent: Monday, November 10, 2003 12:35 PM
> > > To: spr...@li...
> > > Cc: renaud; Kopylenko, Dmitry; Colin Sampaleanu; Bob Lee
> > > Subject: [Springframework-developer] Revised AOP API proposal
> > >
> > >
> > > All,
> > >
> > > Here's a variant on the API API which goes down the path initially 
> > > suggested by Renaud with separate class and method
> > designators. Apart
> > > from that it's much the same: Advice is still almost the same.
> > >
> > > The unit of composition is a ClassFilter or MethodMatcher. The new 
> > > Pointcut interface allows for FieldMatchers in the future.
> > >
> > > Abstract convenience classes could make it easy to use: for
> > example,
> > > the RegexpPointcut could continue to implement Pointcut,
> > with no need
> > > for the application developer to work with a distinct
> > ClassFilter or
> > > MethodMatcher. I think the only downside of this proposal
> > is ease of
> > > use, and convenience classes can resolve that.
> > >
> > > This also enables IntroductionAdvice to have only a ClassFilter, 
> > > as Bob wanted.
> > >
> > > Static methods are still used to "compose" pointcuts and the 
> > > finer-grained units of composition.
> > >
> > > Feedback please... This is an important API to get right,
> > and time is
> > > closing now, as we don't want this to delay M3.
> > >
> > > Regards,
> > > Rod
> > >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by: ApacheCon 2003,
> > 16-19 November in Las Vegas. Learn firsthand the latest developments 
> > in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! 
> > http://www.apachecon.com/ 
> > _______________________________________________
> > Springframework-developer mailing list 
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-develop
> > er
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest developments 
> in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! 
> http://www.apachecon.com/ 
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>




-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest developments in
Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more!
http://www.apachecon.com/ _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Revised AOP API proposal

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

Renaud,

I guess you're right regarding what "advice" should be in AOP. AspectJ is
not the cleanest implementation around.

However, for the moment, I'm going to check in a version with "Advice" as
discussed. (I'm just verifying that the whole test suite runs right now.)

It's fairly easy to refactor to change if necessary later, so we can
continue to discuss this.

I'm not crazy about Advisor. And I suspect that Advice may be clearer to
many, like I, who think of AspectJ concepts.

But let's continue to discuss it, and I'm sure it will be helpful to have
some code out there that implements the basic concepts.

Regarding perInstance, Spring supports this via the BeanFactory's
"singleton/prototype" option or programmatic creation (used a shared
interceptor if you want to). However, I can see that it arguably belongs on
the AOP API.

Spring could probably use a perInstance flag to check that the user has
configured the object correctly, rather than drive the configuration.
However, I'll also leave this out for now pending further discussion.

Regards,
Rod

----- Original Message ----- 
From: "renaud" <re...@ao...>
To: <spr...@li...>
Cc: "'Colin Sampaleanu'" <col...@ex...>; "'Bob Lee'"
<cra...@cr...>
Sent: Tuesday, November 11, 2003 3:23 PM
Subject: RE: [Springframework-developer] Revised AOP API proposal


>
>
> Yes. Actually I do not like the fact that in AspectJ an advice in defined
> regarding a pointcut.
> I've found it very unclear what is exactly the advice in the AspectJ
> semantics.
>
> <AspectJDoc>
> A join point is a well-defined point in the program flow. Pointcuts select
> certain join points and values at those points. Advice defines code that
is
> executed when a pointcut is reached. These are, then, the dynamic parts of
> AspectJ.
> </AspectJDoc>
>
> By reading this, you can really think that the advice and the pointcut are
> orthogonal and defined independently. Indeed, it seems not flexible at all

> to define at the same place the code to be executed and where it is
> executed.
>
> But, later in the same doc:
>
> <AspectJDoc>
> Pointcuts are used in the definition of advice.
> </AspectJDoc>
>
> To me it is confusing. Moreover, lots of work on AOP have pointed out the
> benefits of having independent structures for the both. To me AspectJ
misses
> something here: the ability to define independent (unlocated) advice -- 
like
> an interceptor does.
>
> So it seems to me that the concept of Advisor helps here. It sounds like
> saying "we advise some code" and "we do not use advice concept
specifically
> because it is unclear and, btw, we use interceptors which are independent
> structures - more flexible than the advice constructs in AspectJ".
>
> Regards,
> Renaud.
>
> ---
> Renaud Pawlak
> Software Engineering Department
> Rensselaer at Hartford
> 275 Windsor St, Hartford, CT 06120-2991
> Work: 860-548-5358 Mobile: 860-748-5527
> Emails: pa...@rh..., re...@ao...
> WWW: http://www.lifl.fr/~pawlak
>
>
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]
> >  On Behalf Of Kopylenko, Dmitry
> > Sent: Tuesday, November 11, 2003 9:52 AM
> > To: 'renaud'; 'spr...@li...'
> > Cc: 'Colin Sampaleanu'; 'Bob Lee'
> > Subject: RE: [Springframework-developer] Revised AOP API proposal
> >
> >
> > Advisor does not fall under "standard" AOP concepts as
> > opposed to Advice, but I like the name better.
> >
> > My 2c.
> >
> > Dmitriy.
> >
> > -----Original Message-----
> > From: renaud [mailto:re...@ao...]
> > Sent: Tuesday, November 11, 2003 9:19 AM
> > To: spr...@li...
> > Cc: 'Kopylenko, Dmitry'; 'Colin Sampaleanu'; 'Bob Lee'
> > Subject: RE: [Springframework-developer] Revised AOP API proposal
> >
> >
> >
> > Hi all,
> >
> > I have been working a lot these last days on a JAC
> > refactoring in order that our two frameworks implement a
> > simplar API (well, as much as possible). Morever this allows
> > me to detect weaknesses of the proposed API.
> >
> > Rod, when do you plan to consider the API definitively fixed
> > (so that I kown until when I can work on it)?
> >
> > The main problem I see for now on is about the per-instance
> > property. In AOP, you are supposed to be able to precise if
> > the aspect will be applied globally, or on a per-instance
> > basis. For instance, you may want an advice to install the
> > same interceptor for your whole pointcut, or seamlessly
> > create a different instance for each instance cut by the pointcut.
> >
> > This is not difficult to solve. We can propose a method
> > isPerInstance() on the Advice.
> >
> > By the way, by thinking a lot about this "Advice" interface,
> > it turned out that the concept of advice as defined in AOP (I
> > means theorical AOP) does not includes the pointcut. However,
> > in AspectJ, it actually corresponds to an actual construct.
> > So, I figured out that the best way to solve the issue was to
> > call this construct an "Advisor". Note that it has the
> > advantage to solve the problem of the advice plural
> > ("Advice[] getAdvice()" is not very cool).
> >
> > So my intermediate proposal would be:
> >
> > public interface Advisor {
> >     boolean isPerInstance();
> > }
> >
> > And rename
> > InterceptionAdvice into InterceptionAdvisor
> > IntroductionAdvice into IntroductionAdvisor
> >
> > In the aspect, you will also have a getAdvisors method
> > instead of a getAdvice method.
> >
> > As you can see, it is not a big deal of a change at all.
> >
> > Best,
> > Renaud.
> >
> > ---
> > Renaud Pawlak
> > Software Engineering Department
> > Rensselaer at Hartford
> > 275 Windsor St, Hartford, CT 06120-2991
> > Work: 860-548-5358 Mobile: 860-748-5527
> > Emails: pa...@rh..., re...@ao...
> > WWW: http://www.lifl.fr/~pawlak
> >
> >
> > > -----Original Message-----
> > > From: spr...@li...
> > > [mailto:spr...@li...]
> > >  On Behalf Of Rod Johnson
> > > Sent: Monday, November 10, 2003 12:35 PM
> > > To: spr...@li...
> > > Cc: renaud; Kopylenko, Dmitry; Colin Sampaleanu; Bob Lee
> > > Subject: [Springframework-developer] Revised AOP API proposal
> > >
> > >
> > > All,
> > >
> > > Here's a variant on the API API which goes down the path initially
> > > suggested by Renaud with separate class and method
> > designators. Apart
> > > from that it's much the same: Advice is still almost the same.
> > >
> > > The unit of composition is a ClassFilter or MethodMatcher. The new
> > > Pointcut interface allows for FieldMatchers in the future.
> > >
> > > Abstract convenience classes could make it easy to use: for
> > example,
> > > the RegexpPointcut could continue to implement Pointcut,
> > with no need
> > > for the application developer to work with a distinct
> > ClassFilter or
> > > MethodMatcher. I think the only downside of this proposal
> > is ease of
> > > use, and convenience classes can resolve that.
> > >
> > > This also enables IntroductionAdvice to have only a ClassFilter, as
> > > Bob wanted.
> > >
> > > Static methods are still used to "compose" pointcuts and the
> > > finer-grained units of composition.
> > >
> > > Feedback please... This is an important API to get right,
> > and time is
> > > closing now, as we don't want this to delay M3.
> > >
> > > Regards,
> > > Rod
> > >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by: ApacheCon 2003,
> > 16-19 November in Las Vegas. Learn firsthand the latest
> > developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV,
> > and more! http://www.apachecon.com/
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Fw: [Springframework-developer] Revised AOP API proposal

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

Forwarded on behalf of Bob...



renaud wrote:

>certain join points and values at those points. Advice defines code that is
>executed when a pointcut is reached. These are, then, the dynamic parts of
>AspectJ.
></AspectJDoc>
>
>By reading this, you can really think that the advice and the pointcut are
>orthogonal and defined independently. Indeed, it seems not flexible at all
>to define at the same place the code to be executed and where it is
>executed.
>
>
I think it means that advice maps code to pointcuts.

>To me it is confusing. Moreover, lots of work on AOP have pointed out the
>benefits of having independent structures for the both. To me AspectJ
misses
>something here: the ability to define independent (unlocated) advice -- 
like
>an interceptor does.
>
>
You can map to an abstract pointcut.

I think Advice is the correct term here.

Thanks,
Bob

RE: [Springframework-developer] Revised AOP API proposal

[renaud <re...@ao...>]

Yes. Actually I do not like the fact that in AspectJ an advice in defined
regarding a pointcut. 
I've found it very unclear what is exactly the advice in the AspectJ
semantics.

<AspectJDoc>
A join point is a well-defined point in the program flow. Pointcuts select
certain join points and values at those points. Advice defines code that is
executed when a pointcut is reached. These are, then, the dynamic parts of
AspectJ.
</AspectJDoc>

By reading this, you can really think that the advice and the pointcut are
orthogonal and defined independently. Indeed, it seems not flexible at all
to define at the same place the code to be executed and where it is
executed.

But, later in the same doc:

<AspectJDoc>
Pointcuts are used in the definition of advice.
</AspectJDoc>

To me it is confusing. Moreover, lots of work on AOP have pointed out the
benefits of having independent structures for the both. To me AspectJ misses
something here: the ability to define independent (unlocated) advice -- like
an interceptor does.

So it seems to me that the concept of Advisor helps here. It sounds like
saying "we advise some code" and "we do not use advice concept specifically
because it is unclear and, btw, we use interceptors which are independent
structures - more flexible than the advice constructs in AspectJ".

Regards,
Renaud.

---
Renaud Pawlak
Software Engineering Department
Rensselaer at Hartford
275 Windsor St, Hartford, CT 06120-2991
Work: 860-548-5358 Mobile: 860-748-5527
Emails: pa...@rh..., re...@ao...
WWW: http://www.lifl.fr/~pawlak


> -----Original Message-----
> From: spr...@li... 
> [mailto:spr...@li...]
>  On Behalf Of Kopylenko, Dmitry
> Sent: Tuesday, November 11, 2003 9:52 AM
> To: 'renaud'; 'spr...@li...'
> Cc: 'Colin Sampaleanu'; 'Bob Lee'
> Subject: RE: [Springframework-developer] Revised AOP API proposal
> 
> 
> Advisor does not fall under "standard" AOP concepts as 
> opposed to Advice, but I like the name better.
> 
> My 2c.
> 
> Dmitriy.
> 
> -----Original Message-----
> From: renaud [mailto:re...@ao...] 
> Sent: Tuesday, November 11, 2003 9:19 AM
> To: spr...@li...
> Cc: 'Kopylenko, Dmitry'; 'Colin Sampaleanu'; 'Bob Lee'
> Subject: RE: [Springframework-developer] Revised AOP API proposal
> 
> 
> 
> Hi all,
> 
> I have been working a lot these last days on a JAC 
> refactoring in order that our two frameworks implement a 
> simplar API (well, as much as possible). Morever this allows 
> me to detect weaknesses of the proposed API.
> 
> Rod, when do you plan to consider the API definitively fixed 
> (so that I kown until when I can work on it)?
> 
> The main problem I see for now on is about the per-instance 
> property. In AOP, you are supposed to be able to precise if 
> the aspect will be applied globally, or on a per-instance 
> basis. For instance, you may want an advice to install the 
> same interceptor for your whole pointcut, or seamlessly 
> create a different instance for each instance cut by the pointcut. 
> 
> This is not difficult to solve. We can propose a method 
> isPerInstance() on the Advice.
> 
> By the way, by thinking a lot about this "Advice" interface, 
> it turned out that the concept of advice as defined in AOP (I 
> means theorical AOP) does not includes the pointcut. However, 
> in AspectJ, it actually corresponds to an actual construct. 
> So, I figured out that the best way to solve the issue was to 
> call this construct an "Advisor". Note that it has the 
> advantage to solve the problem of the advice plural 
> ("Advice[] getAdvice()" is not very cool).
> 
> So my intermediate proposal would be:
> 
> public interface Advisor {
>     boolean isPerInstance();
> }
> 
> And rename
> InterceptionAdvice into InterceptionAdvisor 
> IntroductionAdvice into IntroductionAdvisor 
> 
> In the aspect, you will also have a getAdvisors method 
> instead of a getAdvice method.
> 
> As you can see, it is not a big deal of a change at all.
> 
> Best,
> Renaud.
> 
> ---
> Renaud Pawlak
> Software Engineering Department
> Rensselaer at Hartford
> 275 Windsor St, Hartford, CT 06120-2991
> Work: 860-548-5358 Mobile: 860-748-5527
> Emails: pa...@rh..., re...@ao...
> WWW: http://www.lifl.fr/~pawlak
> 
> 
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]
> >  On Behalf Of Rod Johnson
> > Sent: Monday, November 10, 2003 12:35 PM
> > To: spr...@li...
> > Cc: renaud; Kopylenko, Dmitry; Colin Sampaleanu; Bob Lee
> > Subject: [Springframework-developer] Revised AOP API proposal
> > 
> > 
> > All,
> > 
> > Here's a variant on the API API which goes down the path initially 
> > suggested by Renaud with separate class and method 
> designators. Apart 
> > from that it's much the same: Advice is still almost the same.
> > 
> > The unit of composition is a ClassFilter or MethodMatcher. The new 
> > Pointcut interface allows for FieldMatchers in the future.
> > 
> > Abstract convenience classes could make it easy to use: for 
> example, 
> > the RegexpPointcut could continue to implement Pointcut, 
> with no need 
> > for the application developer to work with a distinct 
> ClassFilter or 
> > MethodMatcher. I think the only downside of this proposal 
> is ease of 
> > use, and convenience classes can resolve that.
> > 
> > This also enables IntroductionAdvice to have only a ClassFilter, as 
> > Bob wanted.
> > 
> > Static methods are still used to "compose" pointcuts and the 
> > finer-grained units of composition.
> > 
> > Feedback please... This is an important API to get right, 
> and time is 
> > closing now, as we don't want this to delay M3.
> > 
> > Regards,
> > Rod
> > 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest 
> developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, 
> and more! http://www.apachecon.com/ 
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] Forcing dependencies between singleton beans without one actually being a property of another

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

Juergen,

How do these dependencies get handled in relation to the existing 
dependencies. i.e. Will this figure out that there is a problem if the 
deployer goofs up and for example says (with the new attribute) that 
bean A depends on bean B, but bean B has a property which refers to bean A?


jürgen höller [werk3AT] wrote:

>Colin,
> 
>I guess a "depends-on" attribute is clearer. <ref> is currently just used wherever objects can get passed in, i.e. in <property>, <constructor-arg>, <list>, etc. As dependencies can just be express to beans and not to values, the explicit <ref> element could be misleading. Furthermore, <bean>'s "parent" attribute also references another bean but not via <ref>. A dependency attribute with bean names as values would be similar.
> 
>I've just added "depends-on" as attribute for <bean>, managed via RootBeanDefinitions's new "dependsOn" property. The value can be one or more bean names, separated by any number of spaces or commas. AbstractBeanFactory will simply call getBean for each of those names before creating the bean instance.
> 
>Note that I do not recommend this for general usage but just for special cases like depending on prepared statics (*ugh*) or database preparation on startup. There could be the case of existing classes that work with statics. And for database preparation, it's hard to see why DAOs should have to reference that preparator as a bean property - they still depend on it being initialized and executed first, though.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: Di 11.11.2003 00:11
>An: spr...@li...
>Betreff: [[W3-SPAM]] - Re: [Springframework-developer] Forcing dependencies between singleton beans without one actually being a property of another - Email found in subject
>
>
>
>As opposed to an attribute, you could re-use the 'ref' element, directly
>under the 'bean' element to state a dependency. In fact, my colleage
>didn't look too carefully at the dtd and tried to do that directly, to
>get what he wanted. Having a 'dependency' attribute is probably clearer
>though...
>
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>I've been asked that by co-workers too. In all our cases, we managed to solve the issue by redesigning the application objects so that such side-effects that other beans depend on are avoided. Nevertheless, I've repeatedly considered adding Ant-style "depends" support, possibly via a "depends-on" attribute of the "bean" tag, with a comma-separated list of bean names as value.
>>
>>On bean creation, the bean factory would simply have to call getBean for those bean names first, before actually creating the bean instance. That would be easy enough to add (compared to constructor resolution or such stuff), so I might do this alongside breakfast tomorrow ;-) Are there any objections to such an option? If not, I suggest to add this already for 1.0 M3.
>>
>>Juergen
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von Colin Sampaleanu
>>Gesendet: Mo 10.11.2003 23:26
>>An: spr...@li...
>>Betreff: [[W3-SPAM]] - [Springframework-developer] Forcing dependencies between singleton beans without one actually being a property of another - Email found in subject
>>
>>
>>
>>I had a co-worker ask me if there was a way to force the creation/usage
>>of a singleton bean B to first create another bean, A, without A
>>actually needing to be a property of B. He needs this because A has some
>>side-effects which B depends on, to work properly.
>>
>>Of course there are some artificial ways to cause this to happen, but I
>>can't think of anything too clean. Is this worth adding as a built-in
>>capability?
>>    
>>

RE: [Springframework-developer] Revised AOP API proposal

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

Advisor does not fall under "standard" AOP concepts as opposed to Advice,
but I like the name better.

My 2c.

Dmitriy.

-----Original Message-----
From: renaud [mailto:re...@ao...] 
Sent: Tuesday, November 11, 2003 9:19 AM
To: spr...@li...
Cc: 'Kopylenko, Dmitry'; 'Colin Sampaleanu'; 'Bob Lee'
Subject: RE: [Springframework-developer] Revised AOP API proposal



Hi all,

I have been working a lot these last days on a JAC refactoring in order that
our two frameworks implement a simplar API (well, as much as possible).
Morever this allows me to detect weaknesses of the proposed API.

Rod, when do you plan to consider the API definitively fixed (so that I kown
until when I can work on it)?

The main problem I see for now on is about the per-instance property. In
AOP, you are supposed to be able to precise if the aspect will be applied
globally, or on a per-instance basis. For instance, you may want an advice
to install the same interceptor for your whole pointcut, or seamlessly
create a different instance for each instance cut by the pointcut. 

This is not difficult to solve. We can propose a method isPerInstance() on
the Advice.

By the way, by thinking a lot about this "Advice" interface, it turned out
that the concept of advice as defined in AOP (I means theorical AOP) does
not includes the pointcut. However, in AspectJ, it actually corresponds to
an actual construct. So, I figured out that the best way to solve the issue
was to call this construct an "Advisor". Note that it has the advantage to
solve the problem of the advice plural ("Advice[] getAdvice()" is not very
cool).

So my intermediate proposal would be:

public interface Advisor {
    boolean isPerInstance();
}

And rename
InterceptionAdvice into InterceptionAdvisor 
IntroductionAdvice into IntroductionAdvisor 

In the aspect, you will also have a getAdvisors method instead of a
getAdvice method.

As you can see, it is not a big deal of a change at all.

Best,
Renaud.

---
Renaud Pawlak
Software Engineering Department
Rensselaer at Hartford
275 Windsor St, Hartford, CT 06120-2991
Work: 860-548-5358 Mobile: 860-748-5527
Emails: pa...@rh..., re...@ao...
WWW: http://www.lifl.fr/~pawlak


> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]
>  On Behalf Of Rod Johnson
> Sent: Monday, November 10, 2003 12:35 PM
> To: spr...@li...
> Cc: renaud; Kopylenko, Dmitry; Colin Sampaleanu; Bob Lee
> Subject: [Springframework-developer] Revised AOP API proposal
> 
> 
> All,
> 
> Here's a variant on the API API which goes down the path
> initially suggested by Renaud with separate class and method 
> designators. Apart from that it's much the same: Advice is 
> still almost the same.
> 
> The unit of composition is a ClassFilter or MethodMatcher.
> The new Pointcut interface allows for FieldMatchers in the future.
> 
> Abstract convenience classes could make it easy to use: for
> example, the RegexpPointcut could continue to implement 
> Pointcut, with no need for the application developer to work 
> with a distinct ClassFilter or MethodMatcher. I think the 
> only downside of this proposal is ease of use, and 
> convenience classes can resolve that.
> 
> This also enables IntroductionAdvice to have only a
> ClassFilter, as Bob wanted.
> 
> Static methods are still used to "compose" pointcuts and the
> finer-grained units of composition.
> 
> Feedback please... This is an important API to get right, and
> time is closing now, as we don't want this to delay M3.
> 
> Regards,
> Rod
> 

RE: [Springframework-developer] Revised AOP API proposal

[renaud <re...@ao...>]

Hi all,

I have been working a lot these last days on a JAC refactoring in order that
our two frameworks implement a simplar API (well, as much as possible).
Morever this allows me to detect weaknesses of the proposed API.

Rod, when do you plan to consider the API definitively fixed (so that I kown
until when I can work on it)?

The main problem I see for now on is about the per-instance property. In
AOP, you are supposed to be able to precise if the aspect will be applied
globally, or on a per-instance basis. For instance, you may want an advice
to install the same interceptor for your whole pointcut, or seamlessly
create a different instance for each instance cut by the pointcut. 

This is not difficult to solve. We can propose a method isPerInstance() on
the Advice.

By the way, by thinking a lot about this "Advice" interface, it turned out
that the concept of advice as defined in AOP (I means theorical AOP) does
not includes the pointcut. However, in AspectJ, it actually corresponds to
an actual construct. So, I figured out that the best way to solve the issue
was to call this construct an "Advisor". Note that it has the advantage to
solve the problem of the advice plural ("Advice[] getAdvice()" is not very
cool).

So my intermediate proposal would be:

public interface Advisor {
    boolean isPerInstance();
}

And rename
InterceptionAdvice into InterceptionAdvisor 
IntroductionAdvice into IntroductionAdvisor 

In the aspect, you will also have a getAdvisors method instead of a
getAdvice method.

As you can see, it is not a big deal of a change at all.

Best,
Renaud.

---
Renaud Pawlak
Software Engineering Department
Rensselaer at Hartford
275 Windsor St, Hartford, CT 06120-2991
Work: 860-548-5358 Mobile: 860-748-5527
Emails: pa...@rh..., re...@ao...
WWW: http://www.lifl.fr/~pawlak


> -----Original Message-----
> From: spr...@li... 
> [mailto:spr...@li...]
>  On Behalf Of Rod Johnson
> Sent: Monday, November 10, 2003 12:35 PM
> To: spr...@li...
> Cc: renaud; Kopylenko, Dmitry; Colin Sampaleanu; Bob Lee
> Subject: [Springframework-developer] Revised AOP API proposal
> 
> 
> All,
> 
> Here's a variant on the API API which goes down the path 
> initially suggested by Renaud with separate class and method 
> designators. Apart from that it's much the same: Advice is 
> still almost the same.
> 
> The unit of composition is a ClassFilter or MethodMatcher. 
> The new Pointcut interface allows for FieldMatchers in the future.
> 
> Abstract convenience classes could make it easy to use: for 
> example, the RegexpPointcut could continue to implement 
> Pointcut, with no need for the application developer to work 
> with a distinct ClassFilter or MethodMatcher. I think the 
> only downside of this proposal is ease of use, and 
> convenience classes can resolve that.
> 
> This also enables IntroductionAdvice to have only a 
> ClassFilter, as Bob wanted.
> 
> Static methods are still used to "compose" pointcuts and the 
> finer-grained units of composition.
> 
> Feedback please... This is an important API to get right, and 
> time is closing now, as we don't want this to delay M3.
> 
> Regards,
> Rod
> 

Re: [Springframework-developer] About MVC

[William G. T. Jr. <wg...@ru...>]

You seem to be describing a Portal which has two parts, 1) Portal 
Application which is responsible for aggregating Portlets (your screen 
parts) and targeting a request to a Portlet and 2) Portlet Container 
which is responsible for the lifecyle of Portlets.

Spring could be used to implement the Portal Application which would be 
very close to your Sequence Diagram and would call down into the Portlet 
Container to invoke a Portlet and get the SP.

Each Portlet is in essence a separate web app and could use the standard 
Spring MVC model with some slight modifications (e.g. only return markup 
fragment instead of a whole page).

Talk a look at Portlet API and uPortal.
http://www.jcp.org/aboutJava/communityprocess/review/jsr168/
http://mis105.mis.udel.edu/ja-sig/uportal/

later.
Bill


yan...@ne... wrote:

> All:
> 
> I read "Expert One-on-One - J2EE Design and Development" recently. It is one of the most excellent books I have ever read about enterprise app design.
> 
> But, as I think, there is a problem in its decision on MVC implementation. The proposed solution works very well in simple applications. But when it comes to complicated real application requirement, it seems it can not work properly at least according to current description. It needs extension.
> 
> The Problem:
> In such complication applications as portal, every web page (I call it "Screen" in contrast with View in the MVC) must display a lot of information. Information is grouped in several independent parts (I call it a Screen Part, SP). Views are just SPs, not Screens.
> When the user submit a form (or link to another Screen). Another Screen will be displayed as a response to the input. This new Screen may have a SP display the result of the user action and may have other SPs unrelated to this user action. The spring framework works very good at creating the result SP while not provide good mechanism to produce other unrelated Screen.
> I will describe it in detail.
> 
> 1. Let's examine what the "model" means. 
> The "true", traditional model refers to domain model (DM). 
> As explained in the "The MVC Triad" part of the book, "A model contains data displayed by a view. Models in web applications (as opposed to "true," traditional MVC) are usually dumb storage objects, such as value objects, that represent the result of a complete business operation. Once a controller completes its processing and selects a view to generate content, the model should contain all the data to display. " (I call this kind of model in web app view model, VM).
> 
> 2. Who create the VM?
> As DM always exists in the back ground, the only problem remain is who should take the responsibility to create the VM from DM. 
> (Assumption: Every View has a VM. Every VM could be displayed by several kind of View.)
> A user action (submission a form or following a link) is mapping to a controller. Does the controller know what the user expects to see in the result Screen? No. The controller only knows the result of the action (which is important in the result Screen selection). It doesn't know all other information the user expecting (e.g. information's unrelated to this action). That is a controller should only create the model for one view (a SP in the result Screen). So let the controllers create all the VM for the result Screen is impossible.
> 
> My solution:
> Principle: Seperate the action controller with the view controller.
> The action controller's responsibility is to process the user action and return the result model (contains only data related to this action) and the result Screen name.
> The view controller's responsibility is creating the VM from the DM for a SP.
> 
> I agree with the book that the controller returned with a model and name of "view". But the model should only contain information related to the user action. And the name of "view" should be the name of Screen Model. But this controller is only action controller. 
> Then use a ScreenModelResolver (rather than a ViewResolver) to resolve the Screen Model name to a Screen Model which contains a set of SP Model. Every SP has a view controller to create the VM for this SP. The Screen Model calls all SPs' controller to create their VMs.
> Then use a ScreenResolver to get the concrete Screen and forward the request to this concrete Screen to create the response (by using any mechanism described in the book) and sent back to user.
> 
> As depicted in the attach files.
> 
> What about your opinion? 
> 

[Springframework-developer] About MVC

[<yan...@ne...>]

All:

I read "Expert One-on-One - J2EE Design and Development" recently. It is one of the most excellent books I have ever read about enterprise app design.

But, as I think, there is a problem in its decision on MVC implementation. The proposed solution works very well in simple applications. But when it comes to complicated real application requirement, it seems it can not work properly at least according to current description. It needs extension.

The Problem:
In such complication applications as portal, every web page (I call it "Screen" in contrast with View in the MVC) must display a lot of information. Information is grouped in several independent parts (I call it a Screen Part, SP). Views are just SPs, not Screens.
When the user submit a form (or link to another Screen). Another Screen will be displayed as a response to the input. This new Screen may have a SP display the result of the user action and may have other SPs unrelated to this user action. The spring framework works very good at creating the result SP while not provide good mechanism to produce other unrelated Screen.
I will describe it in detail.

1. Let's examine what the "model" means. 
The "true", traditional model refers to domain model (DM). 
As explained in the "The MVC Triad" part of the book, "A model contains data displayed by a view. Models in web applications (as opposed to "true," traditional MVC) are usually dumb storage objects, such as value objects, that represent the result of a complete business operation. Once a controller completes its processing and selects a view to generate content, the model should contain all the data to display. " (I call this kind of model in web app view model, VM).

2. Who create the VM?
As DM always exists in the back ground, the only problem remain is who should take the responsibility to create the VM from DM. 
(Assumption: Every View has a VM. Every VM could be displayed by several kind of View.)
A user action (submission a form or following a link) is mapping to a controller. Does the controller know what the user expects to see in the result Screen? No. The controller only knows the result of the action (which is important in the result Screen selection). It doesn't know all other information the user expecting (e.g. information's unrelated to this action). That is a controller should only create the model for one view (a SP in the result Screen). So let the controllers create all the VM for the result Screen is impossible.

My solution:
Principle: Seperate the action controller with the view controller.
The action controller's responsibility is to process the user action and return the result model (contains only data related to this action) and the result Screen name.
The view controller's responsibility is creating the VM from the DM for a SP.

I agree with the book that the controller returned with a model and name of "view". But the model should only contain information related to the user action. And the name of "view" should be the name of Screen Model. But this controller is only action controller. 
Then use a ScreenModelResolver (rather than a ViewResolver) to resolve the Screen Model name to a Screen Model which contains a set of SP Model. Every SP has a view controller to create the VM for this SP. The Screen Model calls all SPs' controller to create their VMs.
Then use a ScreenResolver to get the concrete Screen and forward the request to this concrete Screen to create the response (by using any mechanism described in the book) and sent back to user.

As depicted in the attach files.

What about your opinion? 


__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

Re: [Springframework-developer] Forcing dependencies between singleton beans without one actually being a property of another

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

I agree it's not something to encourage, but it's a useful capability. EJB
not having such a capability is one of the pains of using EJB.

(Of course in a distributed environment things are different, hence the lack
of such a feature with EJB.)

Regards,
Rod

----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Tuesday, November 11, 2003 8:15 AM
Subject: Re: [Springframework-developer] Forcing dependencies between
singleton beans without one actually being a property of another


Colin,

I guess a "depends-on" attribute is clearer. <ref> is currently just used
wherever objects can get passed in, i.e. in <property>, <constructor-arg>,
<list>, etc. As dependencies can just be express to beans and not to values,
the explicit <ref> element could be misleading. Furthermore, <bean>'s
"parent" attribute also references another bean but not via <ref>. A
dependency attribute with bean names as values would be similar.

I've just added "depends-on" as attribute for <bean>, managed via
RootBeanDefinitions's new "dependsOn" property. The value can be one or more
bean names, separated by any number of spaces or commas. AbstractBeanFactory
will simply call getBean for each of those names before creating the bean
instance.

Note that I do not recommend this for general usage but just for special
cases like depending on prepared statics (*ugh*) or database preparation on
startup. There could be the case of existing classes that work with statics.
And for database preparation, it's hard to see why DAOs should have to
reference that preparator as a bean property - they still depend on it being
initialized and executed first, though.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Colin Sampaleanu
Gesendet: Di 11.11.2003 00:11
An: spr...@li...
Betreff: [[W3-SPAM]] - Re: [Springframework-developer] Forcing dependencies
between singleton beans without one actually being a property of another -
Email found in subject



As opposed to an attribute, you could re-use the 'ref' element, directly
under the 'bean' element to state a dependency. In fact, my colleage
didn't look too carefully at the dtd and tried to do that directly, to
get what he wanted. Having a 'dependency' attribute is probably clearer
though...


jürgen höller [werk3AT] wrote:

>I've been asked that by co-workers too. In all our cases, we managed to
solve the issue by redesigning the application objects so that such
side-effects that other beans depend on are avoided. Nevertheless, I've
repeatedly considered adding Ant-style "depends" support, possibly via a
"depends-on" attribute of the "bean" tag, with a comma-separated list of
bean names as value.
>
>On bean creation, the bean factory would simply have to call getBean for
those bean names first, before actually creating the bean instance. That
would be easy enough to add (compared to constructor resolution or such
stuff), so I might do this alongside breakfast tomorrow ;-) Are there any
objections to such an option? If not, I suggest to add this already for 1.0
M3.
>
>Juergen
>
>________________________________
>
>Von: spr...@li... im Auftrag von
Colin Sampaleanu
>Gesendet: Mo 10.11.2003 23:26
>An: spr...@li...
>Betreff: [[W3-SPAM]] - [Springframework-developer] Forcing dependencies
between singleton beans without one actually being a property of another -
Email found in subject
>
>
>
>I had a co-worker ask me if there was a way to force the creation/usage
>of a singleton bean B to first create another bean, A, without A
>actually needing to be a property of B. He needs this because A has some
>side-effects which B depends on, to work properly.
>
>Of course there are some artificial ways to cause this to happen, but I
>can't think of anything too clean. Is this worth adding as a built-in
>capability?
>
>




-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Forcing dependencies between singleton beans without one actually being a property of another

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

Colin,
=20
I guess a "depends-on" attribute is clearer. <ref> is currently just =
used wherever objects can get passed in, i.e. in <property>, =
<constructor-arg>, <list>, etc. As dependencies can just be express to =
beans and not to values, the explicit <ref> element could be misleading. =
Furthermore, <bean>'s "parent" attribute also references another bean =
but not via <ref>. A dependency attribute with bean names as values =
would be similar.
=20
I've just added "depends-on" as attribute for <bean>, managed via =
RootBeanDefinitions's new "dependsOn" property. The value can be one or =
more bean names, separated by any number of spaces or commas. =
AbstractBeanFactory will simply call getBean for each of those names =
before creating the bean instance.
=20
Note that I do not recommend this for general usage but just for special =
cases like depending on prepared statics (*ugh*) or database preparation =
on startup. There could be the case of existing classes that work with =
statics. And for database preparation, it's hard to see why DAOs should =
have to reference that preparator as a bean property - they still depend =
on it being initialized and executed first, though.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Di 11.11.2003 00:11
An: spr...@li...
Betreff: [[W3-SPAM]] - Re: [Springframework-developer] Forcing =
dependencies between singleton beans without one actually being a =
property of another - Email found in subject



As opposed to an attribute, you could re-use the 'ref' element, directly
under the 'bean' element to state a dependency. In fact, my colleage
didn't look too carefully at the dtd and tried to do that directly, to
get what he wanted. Having a 'dependency' attribute is probably clearer
though...


j=FCrgen h=F6ller [werk3AT] wrote:

>I've been asked that by co-workers too. In all our cases, we managed to =
solve the issue by redesigning the application objects so that such =
side-effects that other beans depend on are avoided. Nevertheless, I've =
repeatedly considered adding Ant-style "depends" support, possibly via a =
"depends-on" attribute of the "bean" tag, with a comma-separated list of =
bean names as value.
>
>On bean creation, the bean factory would simply have to call getBean =
for those bean names first, before actually creating the bean instance. =
That would be easy enough to add (compared to constructor resolution or =
such stuff), so I might do this alongside breakfast tomorrow ;-) Are =
there any objections to such an option? If not, I suggest to add this =
already for 1.0 M3.
>
>Juergen
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von Colin Sampaleanu
>Gesendet: Mo 10.11.2003 23:26
>An: spr...@li...
>Betreff: [[W3-SPAM]] - [Springframework-developer] Forcing dependencies =
between singleton beans without one actually being a property of another =
- Email found in subject
>
>
>
>I had a co-worker ask me if there was a way to force the creation/usage
>of a singleton bean B to first create another bean, A, without A
>actually needing to be a property of B. He needs this because A has =
some
>side-effects which B depends on, to work properly.
>
>Of course there are some artificial ways to cause this to happen, but I
>can't think of anything too clean. Is this worth adding as a built-in
>capability?
>=20
>




-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Forcing dependencies between singleton beans without one actually being a property of another

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

As opposed to an attribute, you could re-use the 'ref' element, directly 
under the 'bean' element to state a dependency. In fact, my colleage 
didn't look too carefully at the dtd and tried to do that directly, to 
get what he wanted. Having a 'dependency' attribute is probably clearer 
though...


jürgen höller [werk3AT] wrote:

>I've been asked that by co-workers too. In all our cases, we managed to solve the issue by redesigning the application objects so that such side-effects that other beans depend on are avoided. Nevertheless, I've repeatedly considered adding Ant-style "depends" support, possibly via a "depends-on" attribute of the "bean" tag, with a comma-separated list of bean names as value.
> 
>On bean creation, the bean factory would simply have to call getBean for those bean names first, before actually creating the bean instance. That would be easy enough to add (compared to constructor resolution or such stuff), so I might do this alongside breakfast tomorrow ;-) Are there any objections to such an option? If not, I suggest to add this already for 1.0 M3.
> 
>Juergen
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: Mo 10.11.2003 23:26
>An: spr...@li...
>Betreff: [[W3-SPAM]] - [Springframework-developer] Forcing dependencies between singleton beans without one actually being a property of another - Email found in subject
>
>
>
>I had a co-worker ask me if there was a way to force the creation/usage
>of a singleton bean B to first create another bean, A, without A
>actually needing to be a property of B. He needs this because A has some
>side-effects which B depends on, to work properly.
>
>Of course there are some artificial ways to cause this to happen, but I
>can't think of anything too clean. Is this worth adding as a built-in
>capability?
>  
>

Re: [Springframework-developer] Forcing dependencies between singleton beans without one actually being a property of another

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

I've been asked that by co-workers too. In all our cases, we managed to =
solve the issue by redesigning the application objects so that such =
side-effects that other beans depend on are avoided. Nevertheless, I've =
repeatedly considered adding Ant-style "depends" support, possibly via a =
"depends-on" attribute of the "bean" tag, with a comma-separated list of =
bean names as value.
=20
On bean creation, the bean factory would simply have to call getBean for =
those bean names first, before actually creating the bean instance. That =
would be easy enough to add (compared to constructor resolution or such =
stuff), so I might do this alongside breakfast tomorrow ;-) Are there =
any objections to such an option? If not, I suggest to add this already =
for 1.0 M3.
=20
Juergen

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Mo 10.11.2003 23:26
An: spr...@li...
Betreff: [[W3-SPAM]] - [Springframework-developer] Forcing dependencies =
between singleton beans without one actually being a property of another =
- Email found in subject



I had a co-worker ask me if there was a way to force the creation/usage
of a singleton bean B to first create another bean, A, without A
actually needing to be a property of B. He needs this because A has some
side-effects which B depends on, to work properly.

Of course there are some artificial ways to cause this to happen, but I
can't think of anything too clean. Is this worth adding as a built-in
capability?






-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Forcing dependencies between singleton beans without one actually being a property of another

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

I had a co-worker ask me if there was a way to force the creation/usage 
of a singleton bean B to first create another bean, A, without A 
actually needing to be a property of B. He needs this because A has some 
side-effects which B depends on, to work properly.

Of course there are some artificial ways to cause this to happen, but I 
can't think of anything too clean. Is this worth adding as a built-in 
capability?

Re: [Springframework-developer] AOP API Mark II

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

Never here. But if you look at the error log in the message you 
forwarded, it looks like SF mail server is unable to do proper sender 
verification, by getting an mx record for the mail server serving 
'crazybob.org'. I would presume that if bob is able to send to other 
mail servers without problems (a lot of people do callout verification), 
then there may be some sort of routing problem specific to the path 
between sf and his system...  Last time I saw a lot of that kind of 
thing happening was during the big blackout, when some routes were 
totally toasted...



Rod Johnson wrote:

>Bob's in favour of the second cut of the API.
>
>He's having problems posting to the list. Anyone else been having problems
>with the mailing lists?
>
>Regards,
>Rod
>
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: ApacheCon 2003,
>16-19 November in Las Vegas. Learn firsthand the latest
>developments in Apache, PHP, Perl, XML, Java, MySQL,
>WebDAV, and more! http://www.apachecon.com/
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

[Springframework-developer] AOP API Mark II

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

Bob's in favour of the second cut of the API.

He's having problems posting to the list. Anyone else been having problems
with the mailing lists?

Regards,
Rod

Re: [Springframework-developer] Revised AOP API proposal

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

The AOP framework (DefaultProxyConfig) will invoke the implementsInterface()
method on the IntroductionInterceptor to verify. If it returns false it will
throw an AopConfigException. The reason that the IntroductionInterceptor no
longer enumerates the interfaces it introduces is that it may not know every
interface the developer may wish to use it to proxy.

I'm feeling fairly good about this  second proposal. Flattening the two
MethodPointcuts/MethodMatchers means that it's possible to write a method
matcher that implements an expression language that can have express runtime
or static pointcuts.

Regards,
Rod

----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Monday, November 10, 2003 7:07 PM
Subject: Re: [Springframework-developer] Revised AOP API proposal


> This is cleaner. What happens btw if the IntroductionInterceptor can
> handle a subset (as opposed to a superset) of what the Classfilter in
> the IntroductionAdvice says? Just a general failure?
>
>
> Rod Johnson wrote:
>
> >All,
> >
> >Here's a variant on the API API which goes down the path initially
suggested
> >by Renaud with separate class and method designators. Apart from that
it's
> >much the same: Advice is still almost the same.
> >
> >The unit of composition is a ClassFilter or MethodMatcher. The new
Pointcut
> >interface allows for FieldMatchers in the future.
> >
> >Abstract convenience classes could make it easy to use: for example, the
> >RegexpPointcut could continue to implement Pointcut, with no need for the
> >application developer to work with a distinct ClassFilter or
MethodMatcher.
> >I think the only downside of this proposal is ease of use, and
convenience
> >classes can resolve that.
> >
> >This also enables IntroductionAdvice to have only a ClassFilter, as Bob
> >wanted.
> >
> >Static methods are still used to "compose" pointcuts and the
finer-grained
> >units of composition.
> >
> >Feedback please... This is an important API to get right, and time is
> >closing now, as we don't want this to delay M3.
> >
> >Regards,
> >Rod
> >
> >
> >------------------------------------------------------------------------
> >
> >
> >Revised Spring AOP API proposal. Classes and interfaces are unchanged
unless noted. The fundamental implementation strategy won't really need to
change at all.
> >
> >
> >1. Advice
> >
> >An Advice holds a pointcut and interceptor, allowing reuse of both. There
are distinct Advice classes for interception and introduction.
> >
> >
> >
> >Base class used to hold Pointcut and for inclusion in an Aspect (see 6).
> >
> >public abstract interface Advice {
> >
> >
> > // Aspect getAspect();
> >
> >}
> >
> >
> >
> >
> >Advice usable for method or other interception. Spring will support only
method interception:
> >
> >
> >public interface InterceptionAdvice extends Advice {
> >
> > Pointcut getPointcut();
> >
> > Interceptor getInterceptor();
> >
> >
> >}
> >
> >
> >
> >Advice for an introduction. I agree with Bob that this should specify the
interfaces it supports, as an introduction interceptor may implement unknown
interfaces in some cases, and we want to be able to limit the total set of
interfaces exposed according to advice:
> >
> >
> >public interface IntroductionAdvice extends Advice {
> >
> > ClassFilter getClassFilter(); // ******* CHANGED SINCE LAST PROPOSAL
> >
> > IntroductionInterceptor getIntroductionInterceptor();
> >
> > Class[] getInterfaces();
> >
> >}
> >
> >We can still share a ClassFilter between an introduction and other
advice. But now it's impossible to have an Introduction with method-level
pointcut information (which is meaningless and good to rule out).
> >
> >
> >There would be a change on IntroductionInterceptor to allow it to
implement other than a fixed set of interfaces:
> >
> >
> >public IntroductionInterceptor extends Interceptor {
> >
> > boolean implementsInterface(Interface intf);
> >
> >}
> >
> >
> >
> >2. Pointcuts
> >
> >Changed to pretty much what Renaud suggested:
> >
> >
> >interface Pointcut {
> >
> > // A Class filter only narrows the potential choices, making this known
at the time of
> > // proxy creation for potential optimization. It's still necessary to
check the MethodMatcher if
> > // a class matches.
> > ClassFilter getClassFilter();
> >
> > MethodMatcher getMethodMatcher();
> >
> > // FieldMatcher getFieldMatcher(); could be added without breaking the
whole API
> >}
> >
> >
> >See source in attached zip. It even has some comments, although the tests
don't all pass and aren't very good. (They will be by the time I commit the
changes, though :-)
> >
> >I think that static methods are still best to handle composition. A
Pointcuts class of statics is probably necessary as well as
ComposablePointcut, although ComposablePointcut may be useful for
expressions such as
> >
> >ComposablePointcut p = new ComposablePointcut(classFilter);
>
>p.union(classFilter2).intersection(methodMatcher1).intersection(methodMatch
er2);
> >
> >Associativity is L-R. I think this is sufficient!
> >
> >(I haven't included any constructors as yet.)
> >
> >
> >A PointcutComposerFactoryBean will enable a pointcut to be exposed from a
list of Pointcut for convenient use in a BeanFactory.
> >
> >
> >
> >4.ProxyConfig
> >
> >MethodPointcut replaced by Advice methods.
> >
> >Eventually Aspect methods may be added (see 6) but this should be
backward compatible.
> >
> >
> >
> >5. AttributeRegistry
> >
> >The AttributeRegistry will NOT be included in pointcut method signatures.
> >
> >
> >
> >6. Aspects
> >
> >An aspect is a higher-level concept that will be introduced in future,
and will be backward compatible. There will be new methods on ProxyConfig to
handle with Aspects, but none of the Advice functionality will change.
> >
> >public interface Aspect {
> >
> > /**
> > * @return an array of InterceptionAdvice or IntroductionAdvice
> > */
> > Advice[] geAdvice();
> >
> >}
> >
> >
> >7. Convenience classes
> >
> >
> >
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Revised AOP API proposal

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

This is cleaner. What happens btw if the IntroductionInterceptor can 
handle a subset (as opposed to a superset) of what the Classfilter in 
the IntroductionAdvice says? Just a general failure?


Rod Johnson wrote:

>All,
>
>Here's a variant on the API API which goes down the path initially suggested
>by Renaud with separate class and method designators. Apart from that it's
>much the same: Advice is still almost the same.
>
>The unit of composition is a ClassFilter or MethodMatcher. The new Pointcut
>interface allows for FieldMatchers in the future.
>
>Abstract convenience classes could make it easy to use: for example, the
>RegexpPointcut could continue to implement Pointcut, with no need for the
>application developer to work with a distinct ClassFilter or MethodMatcher.
>I think the only downside of this proposal is ease of use, and convenience
>classes can resolve that.
>
>This also enables IntroductionAdvice to have only a ClassFilter, as Bob
>wanted.
>
>Static methods are still used to "compose" pointcuts and the finer-grained
>units of composition.
>
>Feedback please... This is an important API to get right, and time is
>closing now, as we don't want this to delay M3.
>
>Regards,
>Rod
>  
>
>------------------------------------------------------------------------
>
>
>Revised Spring AOP API proposal. Classes and interfaces are unchanged unless noted. The fundamental implementation strategy won't really need to change at all.
>
>
>1. Advice
>
>An Advice holds a pointcut and interceptor, allowing reuse of both. There are distinct Advice classes for interception and introduction.
>
>
>
>Base class used to hold Pointcut and for inclusion in an Aspect (see 6).
>
>public abstract interface Advice {
>
>	
>	// Aspect getAspect();
>
>}
>
>
>
>
>Advice usable for method or other interception. Spring will support only method interception:
>
>
>public interface InterceptionAdvice extends Advice {
>
>	Pointcut getPointcut();
>	
>	Interceptor getInterceptor();
>	
>
>}
>
>
>
>Advice for an introduction. I agree with Bob that this should specify the interfaces it supports, as an introduction interceptor may implement unknown interfaces in some cases, and we want to be able to limit the total set of interfaces exposed according to advice:
>
>
>public interface IntroductionAdvice extends Advice {
>	
>	ClassFilter getClassFilter();	// ******* CHANGED SINCE LAST PROPOSAL
>
>	IntroductionInterceptor getIntroductionInterceptor();
>	
>	Class[] getInterfaces();
>	
>}
>
>We can still share a ClassFilter between an introduction and other advice. But now it's impossible to have an Introduction with method-level pointcut information (which is meaningless and good to rule out).
>
>
>There would be a change on IntroductionInterceptor to allow it to implement other than a fixed set of interfaces:
>
>
>public IntroductionInterceptor extends Interceptor {
>
>	boolean implementsInterface(Interface intf);
>	
>}
>
>
>
>2. Pointcuts
>
>Changed to pretty much what Renaud suggested:
>
>
>interface Pointcut {
>
>	// A Class filter only narrows the potential choices, making this known at the time of
>	// proxy creation for potential optimization. It's still necessary to check the MethodMatcher if
>	// a class matches.
>	ClassFilter getClassFilter();
>	
>	MethodMatcher getMethodMatcher();
>	
>	// FieldMatcher getFieldMatcher(); could be added without breaking the whole API
>}
>
>
>See source in attached zip. It even has some comments, although the tests don't all pass and aren't very good. (They will be by the time I commit the changes, though :-)
>
>I think that static methods are still best to handle composition. A Pointcuts class of statics is probably necessary as well as ComposablePointcut, although ComposablePointcut may be useful for expressions such as
>
>ComposablePointcut p = new ComposablePointcut(classFilter);
>p.union(classFilter2).intersection(methodMatcher1).intersection(methodMatcher2);
>
>Associativity is L-R. I think this is sufficient!
>
>(I haven't included any constructors as yet.)
>
>
>A PointcutComposerFactoryBean will enable a pointcut to be exposed from a list of Pointcut for convenient use in a BeanFactory.
>
>
>
>4.ProxyConfig
>
>MethodPointcut replaced by Advice methods.
>
>Eventually Aspect methods may be added (see 6) but this should be backward compatible.
>
>
>
>5. AttributeRegistry
>
>The AttributeRegistry will NOT be included in pointcut method signatures.
>
>
>
>6. Aspects
>
>An aspect is a higher-level concept that will be introduced in future, and will be backward compatible. There will be new methods on ProxyConfig to handle with Aspects, but none of the Advice functionality will change.
>
>public interface Aspect {
>
>	/**
>	* @return an array of InterceptionAdvice or IntroductionAdvice
>	*/
>	Advice[] geAdvice();
>
>}
>
>
>7. Convenience classes
>
>  
>