springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Moving all build output under 'target'

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

I don't mind the ".classes"/".testclasses"/etc directories being moved, =
but I'm not so sure about the "dist" and "docs/api" directories. They =
are the ones that get included in the release zips, at exactly that =
location: The release zip directory structure matches our CVS module =
structure 1:1 currently (omitting a lot of directories of course), and I =
believe that's a good thing.

Thus, I'd like to keep the docs/api and dist directories where they are. =
The Petclinic and Countries sample apps use similar directories in their =
build scripts, so this is consistent within the whole project. And =
switching from a release zip to a CVS snapshot is straightforward, as =
the directory structures match.

Juergen


Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: Mi 12.11.2003 09:14
An: spr...@li...
Betreff: Re: [Springframework-developer] Moving all build output under =
'target'




> Does anybody object to me changing the build to put all directories =
(and
> thus all artifacts) produced by the build to be under a top-level dir
> called 'target'? I don't find the present setup, with 'x' number of
> directories produced under the project root, to be too clean or very
> standard.

Good idea.



-------------------------------------------------------
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've add an isPerInstance() method on Advice as you suggested. It's not
currently used by the framework, which relies on the user to configure
appropriately using beans or programmatically. However, I may add some
checks or other support, and it's already available for users to query via
the ProxyConfig API.

Regards,
Rod

----- Original Message ----- 
From: "renaud" <re...@ao...>
To: <spr...@li...>
Cc: "'Kopylenko, Dmitry'" <dko...@su...>; "'Colin
Sampaleanu'" <col...@ex...>; "'Bob Lee'" <cra...@cr...>
Sent: Tuesday, November 11, 2003 2:18 PM
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] About MVC

[<dar...@hs...>]

<Alef>
Darren, I've been implementing something like this before, using the
reference data feature of the controllers, works like a charme. However,
It's the problem still is that you end up using _one_ model, where - in
e.g. a portlet - you would somehow want a per-portlet model, scoped,
like in tiles... In your solution, what if one of the beans returns an
entry in the model with the same key as the controller (or another
bean). They override...
</Alef>


yeah, that's actually the way I understood the OP's request - as being a
non-portal scenario, and in some (non-portal) apps it's definitely what
you'd want I think.  For portlets, you would of course need properly scoped
models but I think what was outlined has some validity.

<Alef>
It would however be nice if we could come up with something that's not
specific to views...
</Alef>

Do you not think that configuring some of this peripheral data should be at
the view level?  If not the view, then where..? In common scenarios I come
across, the secondary model is quite specific to a view (though not of
course the TYPE of view)

Darren.




_____________________________________________________

This transmission has been issued by a member of the HSBC Group 
"HSBC" for the information of the addressee only and should not be 
reproduced and / or distributed to any other person. Each page attached 
hereto must be read in conjunction with any disclaimer which forms part 
of it. Unless otherwise stated, this transmission is neither an offer nor the 
solicitation of an offer to sell or purchase any investment. Its contents are 
based on information obtained from sources believed to be reliable but
HSBC makes no representation and accepts no responsibility or liability as 
to its completeness or accuracy.

RE: [Springframework-developer] Fw: [ springframework-Bugs-840442 ] [junit] testDateTimeElement does not pass!!!

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

Has anyone noticed that I erroneously wrote "uncomment" instead of =
"comment out"? ;-) Of course, I don't want to hide some not working test =
case - I just hate test cases that fail on one machine but not the =
other...

BTW, I recently fixed an AOP test case that failed depending on the =
garbage collector - because a counting interceptor got triggered on =
"finalize" too, resulting in count 4 or 3, depending on finalize being =
called in time or not...

Anyway, Darren, thanks for having look at it - would be good to not have =
to worry about that anymore at the time of the M3 release next week.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Wednesday, November 12, 2003 9:46 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Fw: [
springframework-Bugs-840442 ] [junit] testDateTimeElement does not
pass!!!


Yes, it's essential that all unit tests pass at all times.

Regards,
Rod

----- Original Message -----=20
From: <dar...@hs...>
To: <spr...@li...>
Sent: Wednesday, November 12, 2003 8:32 AM
Subject: Re: [Springframework-developer] Fw: [ =
springframework-Bugs-840442 ]
[junit] testDateTimeElement does not pass!!!


>
> <Juergen>
> Does anyone mind if I just uncomment that test method? It gets on my
> nerves, it really does - I've got more important stuff to worry about =
;-)
> Of course, if someone else wants to look at it, have a try... Darren
maybe?
> </Juergen>
>
> I don't really mind - I quickly knocked up the tests a while back when
> doing some XSLT views and they always worked for me (and I guess Rod
> judging by the CVS version history) because we're both in the UK.
>
> Possibly more concerning is whether some dodgy Locale handling =
adversely
> affects anything else, so yes, I'll try to have a look and see what's
wrong
> with it.
>
> Darren.
>
>
>
>
> _____________________________________________________
>
> This transmission has been issued by a member of the HSBC Group
> "HSBC" for the information of the addressee only and should not be
> reproduced and / or distributed to any other person. Each page =
attached
> hereto must be read in conjunction with any disclaimer which forms =
part
> of it. Unless otherwise stated, this transmission is neither an offer =
nor
the
> solicitation of an offer to sell or purchase any investment. Its =
contents
are
> based on information obtained from sources believed to be reliable but
> HSBC makes no representation and accepts no responsibility or =
liability as
> to its completeness or accuracy.
>
>
>
> -------------------------------------------------------
> 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] Fw: [ springframework-Bugs-840442 ] [junit] testDateTimeElement does not pass!!!

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

Yes, it's essential that all unit tests pass at all times.

Regards,
Rod

----- Original Message ----- 
From: <dar...@hs...>
To: <spr...@li...>
Sent: Wednesday, November 12, 2003 8:32 AM
Subject: Re: [Springframework-developer] Fw: [ springframework-Bugs-840442 ]
[junit] testDateTimeElement does not pass!!!


>
> <Juergen>
> Does anyone mind if I just uncomment that test method? It gets on my
> nerves, it really does - I've got more important stuff to worry about ;-)
> Of course, if someone else wants to look at it, have a try... Darren
maybe?
> </Juergen>
>
> I don't really mind - I quickly knocked up the tests a while back when
> doing some XSLT views and they always worked for me (and I guess Rod
> judging by the CVS version history) because we're both in the UK.
>
> Possibly more concerning is whether some dodgy Locale handling adversely
> affects anything else, so yes, I'll try to have a look and see what's
wrong
> with it.
>
> Darren.
>
>
>
>
> _____________________________________________________
>
> This transmission has been issued by a member of the HSBC Group
> "HSBC" for the information of the addressee only and should not be
> reproduced and / or distributed to any other person. Each page attached
> hereto must be read in conjunction with any disclaimer which forms part
> of it. Unless otherwise stated, this transmission is neither an offer nor
the
> solicitation of an offer to sell or purchase any investment. Its contents
are
> based on information obtained from sources believed to be reliable but
> HSBC makes no representation and accepts no responsibility or liability as
> to its completeness or accuracy.
>
>
>
> -------------------------------------------------------
> 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] Fw: [ springframework-Bugs-840442 ] [junit] testDateTimeElement does not pass!!!

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

> Does anyone mind if I just uncomment that test method?

Of course we do :))... 

I don't know what it's about, but we've done a lot of multi-locale stuff
and always end up setting the default locale (Locale.setDefault()) in
the init phase or something (when it somes to Swing based interfaces).
We're doing that for our tests as well and that works fine!

So it might help to just put Locale.setDefault(Locale.UL) in the setUp
method of the TestCase... I wanted to take a look at it, but it was gone
already (the complete test)?

Alef

P.s. Juergen, of course we don't mind :) and err... By the way we should
really throw the guy a party some time after the 1.0 release :)

Re: [Springframework-developer] Fw: [ springframework-Bugs-840442 ] [junit] testDateTimeElement does not pass!!!

[<dar...@hs...>]

<Juergen>
Does anyone mind if I just uncomment that test method? It gets on my
nerves, it really does - I've got more important stuff to worry about ;-)
Of course, if someone else wants to look at it, have a try... Darren maybe?
</Juergen>

I don't really mind - I quickly knocked up the tests a while back when
doing some XSLT views and they always worked for me (and I guess Rod
judging by the CVS version history) because we're both in the UK.

Possibly more concerning is whether some dodgy Locale handling adversely
affects anything else, so yes, I'll try to have a look and see what's wrong
with it.

Darren.




_____________________________________________________

This transmission has been issued by a member of the HSBC Group 
"HSBC" for the information of the addressee only and should not be 
reproduced and / or distributed to any other person. Each page attached 
hereto must be read in conjunction with any disclaimer which forms part 
of it. Unless otherwise stated, this transmission is neither an offer nor the 
solicitation of an offer to sell or purchase any investment. Its contents are 
based on information obtained from sources believed to be reliable but
HSBC makes no representation and accepts no responsibility or liability as 
to its completeness or accuracy.

RE: [Springframework-developer] About MVC

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

> .. is implemented by some arbitrary business objects, then a 
> view could be 
> defined as..

Darren, I've been implementing something like this before, using the
reference data feature of the controllers, works like a charme. However,
It's the problem still is that you end up using _one_ model, where - in
e.g. a portlet - you would somehow want a per-portlet model, scoped,
like in tiles... In your solution, what if one of the beans returns an
entry in the model with the same key as the controller (or another
bean). They override...

The JSP spec does not have any features for scope besides the
app/session/request/page. That's why Tiles added the Tiles scope... But
it's kinda ugly, since it does not work with JSTL tags (jstl of course
does not know the tiles scope). You first have to push all entries in
the pet-tile scpoe to the page scope and them use 'em, argh...

It would however be nice if we could come up with something that's not
specific to views...

Alef

[Springframework-developer] Fw: [ springframework-Bugs-840442 ] [junit] testDateTimeElement does not pass!!!

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

I've repeatedly tried to fix that FormatHelperTests.testDataTimeElement =
method, and there always seems to be some installation where it fails. =
It has definitely something to do with the current machine's locale, but =
it's hard to figure out why the machine's locale is used in the first =
place - the test case feeds Locale.UK into =
FormatHelper.dateTimeElement...
=20
Does anyone mind if I just uncomment that test method? It gets on my =
nerves, it really does - I've got more important stuff to worry about =
;-) Of course, if someone else wants to look at it, have a try... Darren =
maybe?
=20
Juergen

________________________________

Von: SourceForge.net [mailto:no...@so...]
Gesendet: Mi 12.11.2003 07:58
An: no...@so...
Betreff: [ springframework-Bugs-840442 ] [junit] testDateTimeElement =
does not pass!!!



Bugs item #840442, was opened at 2003-11-11 18:36
Message generated for change (Comment added) made by pombredanne
You can respond by visiting:
https://sourceforge.net/tracker/?func=3Ddetail&atid=3D537539&aid=3D840442=
&group_id=3D73357

>Category: Web MVC - general
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: Philippe Ombredanne (pombredanne)
>Assigned to: Juergen Hoeller (jhoeller)
>Summary: [junit] testDateTimeElement does not pass!!!

Initial Comment:
A fresh checked out CVS copy  of spring fails to pass
the test :
org.springframework.web.servlet.view.xslt.FormatHelperTests
testDateTimeElement
Interestingely enough I am in the US using a US locale,
when the test is referring to a UK locale.....
The following asserts do not pass because :
"day-of-week"=3D"Tuesday" not Wednesday
"day-of-month"=3D23 not 24

el =3D (Element)
e.getElementsByTagName("day-of-week").item(0);
assertTrue(
"Wednesday".equals(el.getFirstChild().getNodeValue() ));

el =3D (Element)
e.getElementsByTagName("day-of-month").item(0);
assertTrue(
"24".equals(el.getFirstChild().getNodeValue() ));

I have no idea on how to provide a resolution.
I leave to you .

Please note that the last check-in you made was about
that very same test (see version 1.5 change log)
"mysteriously fails on some installation"
On mine, hours=3D"3", not 12....

BTW, it is not very explicit to use assertTrue for
strings, when assertEquals is much more explicit, and
assertEquals  with a description is always preferred.
Philippe O.



----------------------------------------------------------------------

>Comment By: Philippe Ombredanne (pombredanne)
Date: 2003-11-11 22:58

Message:
Logged In: YES
user_id=3D879778

In fact I figured out the problem!
You DO NOT factor in the Time Zone in your code.
Hence the Date object offset the given time with the time zone.
I reckon that you have run that test only in a time zone of
GMT+1! When I change my system time zone to GMT+1, the test
pass OK.
To reproduce the bug, just change your system time zone on
your test system, and your will see how the test fails.
The FormatHelper dateTimeElement method needs to be changed
accordingly so the tests pass correctly.
BTW, I wonder how to set different "system" time zones
automatically for the tests....
Also the code that was commented :
     /*
                 * // mysteriously fails on some installation el =3D =
(Element)
                 * e.getElementsByTagName("hours").item(0); =
assertEquals(
"12",
                 * el.getFirstChild().getNodeValue() );
                 */

was probably failing for the same reason!!!
Cheers
Philippe O.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=3Ddetail&atid=3D537539&aid=3D840442=
&group_id=3D73357

Re: [Springframework-developer] Moving all build output under 'target'

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

> Does anybody object to me changing the build to put all directories (and 
> thus all artifacts) produced by the build to be under a top-level dir 
> called 'target'? I don't find the present setup, with 'x' number of 
> directories produced under the project root, to be too clean or very 
> standard.

Good idea.

Re: [Springframework-developer] AOP API changes

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

Yes. Most of the app is actually unusable right now due to an ongoing 
refactoring that's affecting a lot of things, so I can't say that this 
is a very thorough test, but I did run through some functionality that 
reads data (ultimately via Hibernate) via some services wrapped with 
declarative transactions. The log output from the  
TransactionInterceptor is there, so it's definitely kicking in. All the 
other Spring functionality I'm using (contexts and the Hibernate related 
code) seems to be ok too.


Rod Johnson wrote:

>Does it use AOP behind the scenes for declarative transaction management?
>
>----- Original Message ----- 
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Tuesday, November 11, 2003 11:00 PM
>Subject: Re: [Springframework-developer] AOP API changes
>
>
>  
>
>>Ok, I am able to build and run all tests ok, with the exception of 
>>FormatHelperTests, which builds ok but fails.
>>
>>I've modified build.xml to fail on any javac errors on any of the 
>>targets using javac.
>>
>>I have also tried this build of Spring with my main app using Spring, 
>>which does _not_ use any of the AOP stuff directly, and all seems to 
>>work ok.
>>
>>
>>
>>Kopylenko, Dmitry wrote:
>>
>>    
>>
>>>I just fixed it. Please re-sync.
>>>
>>>Dmitriy.
>>>
>>>-----Original Message-----
>>>From: Colin Sampaleanu
>>>To: spr...@li...;
>>>dko...@ac...
>>>Sent: 11/11/2003 4:49 PM
>>>Subject: Re: [Springframework-developer] AOP API changes
>>>
>>>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] About MVC

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

On Tuesday 11 November 2003 23:27, Darren Davison wrote:

> Is there something already in Spring MVC that lends itself to this kind
> of behaviour?

without really thinking this through much (since it's gone 1:30am and I have 
to be up again in 4 hours)..

If an interface..

public interface ModelReference {
    public Map getModel();
}

.. is implemented by some arbitrary business objects, then a view could be 
defined as..

<bean id="myVelocityView"
  class="org.springframework.web.servlet.view.velocity.VelocityView">
  <property name="templateName"><value>main.vm</value></property>   
  <!-- standard attribs -->
  <property name="attributes">
    <props>
      <prop key="title">A Velocity Page</prop>
    </props>
  </property>  

  <!-- new property: list of ModelReference implementing bus. objects -->
  <property name="references">
    <list>
      <ref external="myBean"/>
      <ref external="myOtherBean"/>
    </list>
  </property>           
</bean>


AbstractView is amended with the following (part pseudo-code)..

public abstract class AbstractView extends WebApplicationObjectSupport 
implements View {

  //added
  private Map referenceObjects = new HashMap();

  ...

  //added
  public final void setReferencesList(List references) {    
    for each list item
      get bean from app context if exists
      if bean instanceof ModelReference 
        call bean.getModel() 
        consolidate into referenceObjects field
      end
    end
  }

  //amended
  public final void render(Map model, HttpServletRequest request, 
HttpServletResponse response)
  
    ...
    Map mergedModel = new HashMap(this.staticAttributes);
    mergedModel.putAll(referenceObjects);
    mergedModel.putAll(model);
    ...
  }

}


 - The controller still has final say and can overwrite model values from 
the static list or the reference list

 - Arbitrary beans can now add to the model that a view renders on a per 
view basis taking advantage of whatever container resources or custom logic 
is required

 - multiple views can use the same ref objects via the hierarchical view 
structure

 - It's a kind of half-way house between static attributes and model data 
returned by the controller but as shown isn't parameterised so reasonably 
rigid

 - maybe the interface can be dropped and the actual method to call for any 
given bean can be specified in the config too.  One less dependency for the 
business object


Goodnight.


-- 

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

RE: [Springframework-developer] About MVC

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

> You can handle such cases using the tiles support in Spring.
Yup, indeed. The thing is however, that you're tying yourself in to
Tiles and JSP's then... I've always been looking at ways to solve this
problem without specifying view technologies, still no solutions
found...

> There is some info at 
> www.springframework.org/docs/integration/tiles> .html , 
> but 
> the controllers are not mentioned.
I'm working on documentation for MVC, this will be part of it as well...
The example however shows some tiles-component stuff to get you going.

Re: [Springframework-developer] Moving all build output under 'target'

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

On Tuesday 11 November 2003 23:25, Colin Sampaleanu wrote:
> Does anybody object to me changing the build to put all directories (and
> thus all artifacts) produced by the build to be under a top-level dir
> called 'target'? I don't find the present setup, with 'x' number of
> directories produced under the project root, to be too clean or very
> standard.

 +1

-- 

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

Re: [Springframework-developer] AOP API changes

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

Does it use AOP behind the scenes for declarative transaction management?

----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Tuesday, November 11, 2003 11:00 PM
Subject: Re: [Springframework-developer] AOP API changes


> Ok, I am able to build and run all tests ok, with the exception of 
> FormatHelperTests, which builds ok but fails.
> 
> I've modified build.xml to fail on any javac errors on any of the 
> targets using javac.
> 
> I have also tried this build of Spring with my main app using Spring, 
> which does _not_ use any of the AOP stuff directly, and all seems to 
> work ok.
> 
> 
> 
> Kopylenko, Dmitry wrote:
> 
> >I just fixed it. Please re-sync.
> >
> >Dmitriy.
> >
> >-----Original Message-----
> >From: Colin Sampaleanu
> >To: spr...@li...;
> >dko...@ac...
> >Sent: 11/11/2003 4:49 PM
> >Subject: Re: [Springframework-developer] AOP API changes
> >
> >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

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

+1. Should be true.

----- Original Message ----- 
From: "Alef Arendsen (JTeam)" <al...@jt...>
To: <spr...@li...>
Sent: Tuesday, November 11, 2003 10:12 PM
Subject: RE: [Springframework-developer] AOP API changes


> 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
> > 
> 
> 
> 
> -------------------------------------------------------
> 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] Using the bean container/factory

[Ross M. <ro...@at...>]

Hi,
I have a question and I appologise before hand if it sounds stupid, but =
I've just started using Spring ;-)

Is there way to pass a bean to a Spring factory (or container?) and =
return the bean with it's properties autowired based on whats already =
avaliable in the container? =20
Further to this, could you pass in a bean with a map of references to =
populate?

Thanks,

Ross

Re: [Springframework-developer] About MVC

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

On Tuesday 11 November 2003 22:21, Christophe Vanfleteren wrote:

> You can handle such cases using the tiles support in Spring.

correct, but perhaps the problem has a wider scope.  An app shouldn't be 
forced to use tiles to get around it IMO, nor do you want redundant and 
high maintenance code in every controller.  

Conceptually, the model that a controller returns should be capable of being 
added to (decorated) with the peripheral data as configured at the view 
level.  Something akin to a servlet Filter, or Sitemesh on steroids.  This 
would leave the controllers lean and focused solely on translating user 
requests into model/view combinations as they are presently.  The 
'model-decorators' are free to add to this combination the secondary stuff 
that is independant of the user request but which still may require the 
services of business and/or data objects.

Is there something already in Spring MVC that lends itself to this kind of 
behaviour?

Best wishes,

-- 

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

[Springframework-developer] Moving all build output under 'target'

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

Does anybody object to me changing the build to put all directories (and 
thus all artifacts) produced by the build to be under a top-level dir 
called 'target'? I don't find the present setup, with 'x' number of 
directories produced under the project root, to be too clean or very 
standard.

[Springframework-developer] PDF

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

Alef,

The PDF reference manual is looking good! It's definitely going to be very
helpful for users, and very professional, by the time of the 1.0 release.

Regards,
Rod

[Springframework-developer] Documentation - committing soon

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

There's a new (WORK IN PROGRESS) pdf in the docs directory containing a
more elaborate beans package chapter (still not satisfied with it) and
some more info on mvc fileupload. It's about doubled in size and in
pages

I'm going to commit the sources I think in a couple of days (won't be
tomorrow, but probable Thursday). I plan to put a reference directory in
the docs directory, containing the sources and the libraries needed for
generation of documentation. Then, there will be a build-time-generated
pdf, html and html_single directory in the reference directory
(basically it's taken from Hibernate, which is ok, if we mention them
somewhere, according to Hib's Christian Bauer). There will be additional
targets in the build.xml for generating html, html-single and pdf docs
(just three or four targets).

One point of concern, the reference directory will start with a size of
___11 MEGABYTES!!!___. This is quite huge already, and it's going to be
bigger when pictures and more text comes in (but not a lot, because it's
mainly the libraries that do it, fop=2mb, batik=2mb, jai=1,5mb,
docbook-xsl=3,5mb).

I'll omit the lib directory until further notice, unless everybody
agrees to put the libs in as well...

Alef

P.s. I never really use the priorities in emails, but it's sure handy to
indicate a not-so-important mail :)..
P.p.s. don't mind the image in the beans-chapter having a strnage
layout, still work-in-progress :)

Re: [Springframework-developer] AOP API changes

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

Ok, I am able to build and run all tests ok, with the exception of 
FormatHelperTests, which builds ok but fails.

I've modified build.xml to fail on any javac errors on any of the 
targets using javac.

I have also tried this build of Spring with my main app using Spring, 
which does _not_ use any of the AOP stuff directly, and all seems to 
work ok.



Kopylenko, Dmitry wrote:

>I just fixed it. Please re-sync.
>
>Dmitriy.
>
>-----Original Message-----
>From: Colin Sampaleanu
>To: spr...@li...;
>dko...@ac...
>Sent: 11/11/2003 4:49 PM
>Subject: Re: [Springframework-developer] AOP API changes
>
>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...>]

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

RE: [Springframework-developer] AOP API changes

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

I just fixed it. Please re-sync.

Dmitriy.

-----Original Message-----
From: Colin Sampaleanu
To: spr...@li...;
dko...@ac...
Sent: 11/11/2003 4:49 PM
Subject: Re: [Springframework-developer] AOP API changes

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] About MVC

[Christophe V. <c.v...@pa...>]

On Tuesday 11 November 2003 21:30, Darren Davison wrote:
> 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,

You can handle such cases using the tiles support in Spring.

Define a component in tiles, and designate a ComponentControllerSupport 
subclass to it in your tiles config file, like this:

<definition name="name" page="/somepage.jsp" controllerClass="subclass of 
ComponentControllerSupport"/>

In that subclass, you fetch all the data that is required as the model for the 
view (the tiles component, which is a regular jsp page).

There is some info at www.springframework.org/docs/integration/tiles.html , 
but the controllers are not mentioned.

-- 
Kind regards,
Christophe Vanfleteren