springframework-developer — Spring Framework developers list

Re: [Springframework-developer] AOP changes

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

I've just updated to the Commons Attributes snapshot from January 15th. =
Note that the "@@" syntax is now required for attribute definitions; I =
had to adapt our auto-proxying test cases accordingly to make them pass =
again.
=20
One remaining issue is the state of AOP Alliance. The aopalliance.jar =
that we bundle dates back to October; shouldn't we do another AOP =
Alliance release here and update our jar? In terms of name, we ship AOP =
Alliance alpha 1 currently; that's also not very convincing. Couldn't we =
at least do an AOP Alliance beta 1 release for Spring 1.0 final?
=20
Even if most users don't work at the AOP framework level anyway, I =
consider it important to clarify things in that respect. It's bad enough =
that we have to ship a snapshot of Commons Attributes (they can't do a =
proper release while being in the Jakarta sandbox, according to Apache =
rules).
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: So 22.02.2004 22:57
An: spr...@li...
Betreff: Re: [Springframework-developer] AOP changes



I've just committed all my remaining changes. Please test promptly :-)

Juergen


________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: So 22.02.2004 20:44
An: spr...@li...
Betreff: Re: [Springframework-developer] AOP changes



Funny coincidence: I thought about the need for a quick RC2 release this =
weekend (even if I had a family/friends weekend ;-)

If we consolidate everything promptly, a mid-week RC2 release would be =
manageable. I'll commit the one thing that I haven't yet (the "type" =
argument for the constructor-arg tag) tomorrow. Please test everything =
on Tuesday and Wednesday then; I suggest to release RC2 Wednesday night.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: So 22.02.2004 11:01
An: spr...@li...
Betreff: [Springframework-developer] AOP changes



All,

I've just committed some changes to the Advisor hierarchy, to get rid of =
the
parallel hierarchy between Advisors and Advices, which was bothering me.

Now instead of having a hierarchy of Advisors, Advisor has a getAdvice()
method that returns Object. It can't be more strongly typed because of =
AOP
Alliance compliance. Originally I think I wanted to get away from such =
weak
typing, but I'm just not happy with the old parallel class hierarchices.
There are no longer specific Advisor subclasses, like
DefaultMethodBeforeAdvisor: their's just DefaultPointcutAdvisor. An =
Advisor
has a pointcut associated with it or not.

There are quite a few fewer classes in the new approach (-17 I think). =
And
it's more flexible, as DefaultPointcutAdvisor can be reused for any =
advice
type.

The impact on user code should be quite small. If you've extended one of
those advisors, extend the appropriate generic PointcutAdvisor subclass.
RegExpMethodPointcutAdvisor now replaces the old Around advice pointcut
advisor.

The changes make it possible to reuse the regexp pointcut advisor (or =
other
pointcut advisor subclasses) for any kind of advice.

Because this is a public API change, I think we need to consider going =
RC2,
instead of straight to 1.0 now. I was strongly in favour of going =
straight
to 1.0, but there have also been some other public API changes (notably =
in
JDBC) as well as the new Quartz functionality, so I vote for a quick =
release
of RC2 (early this week) and a goal of 1.0 2 weeks after that, with NO =
more
changes except bug fixes.

Regards,
Rod




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Velocity Tools

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

> In general, I wonder why the Velocity project is moving so slowly. It t=
ook
> them over half a year to move from 1.3.1 RC1 to 1.3.1 final. Velocity
> Tools 1.1 final could easily have been released last autumn: After all,
> it's just a couple of straightforward, pretty simple hellper classes. T=
his
> definitely doesn't help in terms of Velocity adoption.

you're right.  In fact it has been remarked upon by less kind people that
Velocity is dead.  The site says they are working on a 1.5 branch but the
CVS repository shows very few changes to any source code in the last year=
.
 At the end of the day, it's not a major problem for most users.  It's a
stable tool that does a specific job fairly well - most of my tests
suggest it's still ahead of JSP in performance terms and the majority of
graphic designers (IME) prefer it to an xml-based sytax.

I think though that they may have lost some mindshare (if not some
developers) to FreeMarker.  On which note, if no-one else is intending to
do it, I'm planning on looking at a FreeMarker integration along similar
lines to the Velocity integration for Spring 1.1

Regards,

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

[Springframework-developer] Velocity Tools

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

Dear Spring/Velocity users,
=20
I've updated our VelocityView to Velocity Tools 1.1 RC1: There's not =
only an optional "dateToolAttribute" (Velocity Tools 1.0) now but also a =
"numberToolAttribute" (new in 1.1). Both are automatically exposed as =
locale-aware subclasses, so that they are aware of the current =
Spring-managed request locale.
=20
Such helper classes are long overdue: I never understood why standard =
Velocity does not provide any means for such important tasks as date and =
number formatting. Particularly in face of the nice formatting options =
that the JSTL offers for JSP, it's good to see that there shouldn't be a =
need to code one's own formatting helpers for Velocity anymore.
=20
In general, I wonder why the Velocity project is moving so slowly. It =
took them over half a year to move from 1.3.1 RC1 to 1.3.1 final. =
Velocity Tools 1.1 final could easily have been released last autumn: =
After all, it's just a couple of straightforward, pretty simple hellper =
classes. This definitely doesn't help in terms of Velocity adoption.
=20
Juergen
=20

Re: [Springframework-developer] I would like to remove JdbcTemplate/JdbcAccessor eager init of exception translator

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

Well, it's quite easy to make it configurable (in the fashion I 
mentioned below). However, somebody putting it in the context, where 
it's easy to configure, would probably not even care about the eager 
init, since they'll be using it as a singleton. On the other hand, 
somebody using 'new JdbcTemplate(datasource, eagerInitFlag), who would 
benefit from not doing the eager init unless absolutely necessary, since 
they are using non-singleton instances, probably has no easy way to 
configure that value. The whole point was to not have to pass both a 
datasource and jdbctemplate to various component, but only a datasource. 
If an eager init config flag is passed, then the jdbctemplate can just 
as readily be passed.

There are probably still a few edge cases where the flag would be useful 
though...

Regards,
Colin

tri...@tr... wrote:

>Maybe we could make lazy init it configurable with the default beeing eager
>init.  I'll give it some thouhgt this week - maybe we can squeeze it in before RC2.
>
>Thomas
>
>Quoting Colin Sampaleanu <col...@ex...>:
>
>  
>
>>Hmm, too bad.   The problem is that if you can get your hands on the 
>>database name, which is something that you would never want to hard-code 
>>in your code, then you can probably also just get your hands on a 
>>jdbcTemplate instance from the context, used as a singleton.   I was 
>>hoping to just make 'new jdbcTemplate(datasource)' as efficient as that 
>>approach...
>>
>>
>>tri...@tr... wrote:
>>
>>    
>>
>>>Colin,
>>>
>>>I think Rod did make it lazy init at some point, but the problem was that
>>>      
>>>
>>some
>>    
>>
>>>jdbc driver (I think MS SQL Server) was not letting us use the connection
>>>      
>>>
>>after
>>    
>>
>>>some exception was thrown.  This prevented us from loading the meta data and
>>>      
>>>
>>the
>>    
>>
>>>translation mapping.  
>>>
>>>All we really need is the database product name, so if you
>>>could set that explicitly, then we don't need to look it up.  
>>>
>>>There is already code in SQLErrorCodesFactory to avoid the database
>>>      
>>>
>>metadata
>>    
>>
>>>lookup if you pass in a database product name.
>>>
>>> public SQLErrorCodes getErrorCodes(String dbName)
>>>
>>>I think all you need now is to do is create a custom 
>>>SQLErrorCodeSQLExceptionTranslator where you set the database product name
>>>explicitly and load the error codes using this rather than the data source.
>>>
>>>Thomas
>>>
>>>
>>>
>>>Quoting Colin Sampaleanu <col...@ex...>:
>>>
>>> 
>>>
>>>      
>>>
>>>>I've been sitting here all day watching logs go by as I try to get a 
>>>>system into production, and seeing a lot of pauses as the
>>>> new JdbcTemplate(dataSource)
>>>>in JdbcHelper causes, every single time JdbcHelper is created, the 
>>>>exception metadata to be pulled from the DB.
>>>>
>>>>Now this is code using Spring slightly post RC1. I realize JdbcHelper 
>>>>has gone away, but the same thing happens of course when you just do a 
>>>>'new JdbcTemplate(dataSource)' directly.
>>>>
>>>>I don't know why JdbcAccessor (and hence JdbcTemplate) really needs to 
>>>>eager init the exception translator. The access method is synchronized, 
>>>>so there should be no issues letting it lazy init.
>>>>
>>>>I would like to remove this eager init (in afterPropertiesSet()) of the 
>>>>exception translator. Please let me know if you have a problem with 
>>>>this. I was thinking that if somebody wants to still allow it to be 
>>>>eagerly inited, for the case where JdbcTemplate is coming out of a 
>>>>beanfactory/context then we can add a 'lazyInitExceptionTranslator' 
>>>>property, which would default to true.
>>>>
>>>>Regards,
>>>>Colin
>>>>
>>>>   
>>>>

Re: [Springframework-developer] I would like to remove JdbcTemplate/JdbcAccessor eager init of exception translator

[<tri...@tr...>]

Maybe we could make lazy init it configurable with the default beeing eager
init.  I'll give it some thouhgt this week - maybe we can squeeze it in before RC2.

Thomas

Quoting Colin Sampaleanu <col...@ex...>:

> Hmm, too bad.   The problem is that if you can get your hands on the 
> database name, which is something that you would never want to hard-code 
> in your code, then you can probably also just get your hands on a 
> jdbcTemplate instance from the context, used as a singleton.   I was 
> hoping to just make 'new jdbcTemplate(datasource)' as efficient as that 
> approach...
> 
> 
> tri...@tr... wrote:
> 
> >Colin,
> >
> >I think Rod did make it lazy init at some point, but the problem was that
> some
> >jdbc driver (I think MS SQL Server) was not letting us use the connection
> after
> >some exception was thrown.  This prevented us from loading the meta data and
> the
> >translation mapping.  
> >
> >All we really need is the database product name, so if you
> >could set that explicitly, then we don't need to look it up.  
> >
> >There is already code in SQLErrorCodesFactory to avoid the database
> metadata
> >lookup if you pass in a database product name.
> >
> >  public SQLErrorCodes getErrorCodes(String dbName)
> >
> >I think all you need now is to do is create a custom 
> >SQLErrorCodeSQLExceptionTranslator where you set the database product name
> >explicitly and load the error codes using this rather than the data source.
> >
> >Thomas
> >
> >
> >
> >Quoting Colin Sampaleanu <col...@ex...>:
> >
> >  
> >
> >>I've been sitting here all day watching logs go by as I try to get a 
> >>system into production, and seeing a lot of pauses as the
> >>  new JdbcTemplate(dataSource)
> >>in JdbcHelper causes, every single time JdbcHelper is created, the 
> >>exception metadata to be pulled from the DB.
> >>
> >>Now this is code using Spring slightly post RC1. I realize JdbcHelper 
> >>has gone away, but the same thing happens of course when you just do a 
> >>'new JdbcTemplate(dataSource)' directly.
> >>
> >>I don't know why JdbcAccessor (and hence JdbcTemplate) really needs to 
> >>eager init the exception translator. The access method is synchronized, 
> >>so there should be no issues letting it lazy init.
> >>
> >>I would like to remove this eager init (in afterPropertiesSet()) of the 
> >>exception translator. Please let me know if you have a problem with 
> >>this. I was thinking that if somebody wants to still allow it to be 
> >>eagerly inited, for the case where JdbcTemplate is coming out of a 
> >>beanfactory/context then we can add a 'lazyInitExceptionTranslator' 
> >>property, which would default to true.
> >>
> >>Regards,
> >>Colin
> >>
> >>    
> >>
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] AOP changes

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

I've just committed all my remaining changes. Please test promptly :-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: So 22.02.2004 20:44
An: spr...@li...
Betreff: Re: [Springframework-developer] AOP changes



Funny coincidence: I thought about the need for a quick RC2 release this =
weekend (even if I had a family/friends weekend ;-)

If we consolidate everything promptly, a mid-week RC2 release would be =
manageable. I'll commit the one thing that I haven't yet (the "type" =
argument for the constructor-arg tag) tomorrow. Please test everything =
on Tuesday and Wednesday then; I suggest to release RC2 Wednesday night.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: So 22.02.2004 11:01
An: spr...@li...
Betreff: [Springframework-developer] AOP changes



All,

I've just committed some changes to the Advisor hierarchy, to get rid of =
the
parallel hierarchy between Advisors and Advices, which was bothering me.

Now instead of having a hierarchy of Advisors, Advisor has a getAdvice()
method that returns Object. It can't be more strongly typed because of =
AOP
Alliance compliance. Originally I think I wanted to get away from such =
weak
typing, but I'm just not happy with the old parallel class hierarchices.
There are no longer specific Advisor subclasses, like
DefaultMethodBeforeAdvisor: their's just DefaultPointcutAdvisor. An =
Advisor
has a pointcut associated with it or not.

There are quite a few fewer classes in the new approach (-17 I think). =
And
it's more flexible, as DefaultPointcutAdvisor can be reused for any =
advice
type.

The impact on user code should be quite small. If you've extended one of
those advisors, extend the appropriate generic PointcutAdvisor subclass.
RegExpMethodPointcutAdvisor now replaces the old Around advice pointcut
advisor.

The changes make it possible to reuse the regexp pointcut advisor (or =
other
pointcut advisor subclasses) for any kind of advice.

Because this is a public API change, I think we need to consider going =
RC2,
instead of straight to 1.0 now. I was strongly in favour of going =
straight
to 1.0, but there have also been some other public API changes (notably =
in
JDBC) as well as the new Quartz functionality, so I vote for a quick =
release
of RC2 (early this week) and a goal of 1.0 2 weeks after that, with NO =
more
changes except bug fixes.

Regards,
Rod




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] AOP changes

[Dmitriy K. <dko...@ru...>]

...yeah, I know, I know.. :-)

And I really appreciate the changes! :-) It looks good!

----- Original Message -----
From: Rod Johnson <rod...@in...>
Date: Sunday, February 22, 2004 11:34 am
Subject: Re: [Springframework-developer] AOP changes

> It shouldn't have much impact on apps. Just simple class name 
> substitution,from whatever to DefaultPointcutAdvisor or to 
> RegexpMethodPointcutAdvisor.
> I've also simplified the implementation of the aop.adapter package 
> followingthe earlier changes. This doesn't affect applications at 
> all. Indeed, I
> didn't change the test suite at all.
> 
> Regards,
> Rod
> 
> ----- Original Message -----
> From: "Dmitriy Kopylenko" <dko...@ru...>
> To: <spr...@li...>
> Sent: Sunday, February 22, 2004 2:39 PM
> Subject: Re: [Springframework-developer] AOP changes
> 
> 
> > me too...
> >
> > it also means that I would need to do some refactoring on my 
> apps... :-(
> >
> > ----- Original Message -----
> > From: Colin Sampaleanu <col...@ex...>
> > Date: Sunday, February 22, 2004 8:22 am
> > Subject: Re: [Springframework-developer] AOP changes
> >
> > > +1 on the RC2
> > >
> > > Rod Johnson wrote:
> > >
> > > >All,
> > > >
> > > >I've just committed some changes to the Advisor hierarchy, to get
> > > rid of the
> > > >parallel hierarchy between Advisors and Advices, which was
> > > bothering me.
> > > >
> > > >Now instead of having a hierarchy of Advisors, Advisor has a
> > > getAdvice()>method that returns Object. It can't be more strongly
> > > typed because of AOP
> > > >Alliance compliance. Originally I think I wanted to get away from
> > > such weak
> > > >typing, but I'm just not happy with the old parallel class
> > > hierarchices.>There are no longer specific Advisor subclasses, 
> like> > >DefaultMethodBeforeAdvisor: their's just 
> DefaultPointcutAdvisor.> > An Advisor
> > > >has a pointcut associated with it or not.
> > > >
> > > >There are quite a few fewer classes in the new approach (-17 I
> > > think). And
> > > >it's more flexible, as DefaultPointcutAdvisor can be reused for
> > > any advice
> > > >type.
> > > >
> > > >The impact on user code should be quite small. If you've extended
> > > one of
> > > >those advisors, extend the appropriate generic PointcutAdvisor
> > > subclass.>RegExpMethodPointcutAdvisor now replaces the old Around
> > > advice pointcut
> > > >advisor.
> > > >
> > > >The changes make it possible to reuse the regexp pointcut advisor
> > > (or other
> > > >pointcut advisor subclasses) for any kind of advice.
> > > >
> > > >Because this is a public API change, I think we need to consider
> > > going RC2,
> > > >instead of straight to 1.0 now. I was strongly in favour of going
> > > straight>to 1.0, but there have also been some other public API
> > > changes (notably in
> > > >JDBC) as well as the new Quartz functionality, so I vote for a
> > > quick release
> > > >of RC2 (early this week) and a goal of 1.0 2 weeks after that,
> > > with NO more
> > > >changes except bug fixes.
> > > >
> > > >Regards,
> > > >Rod
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > > Build and deploy apps & Web services for Linux with
> > > a free DVD software kit from IBM. Click Now!
> > > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-
> developer> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > Build and deploy apps & Web services for Linux with
> > a free DVD software kit from IBM. Click Now!
> > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-
> developer>
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] DTD versioning

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

-1. Anything that reduces confusion is good, in my opinion. If something 
in the xml changes, and the DTD changes, and your xml editor now shows 
that something is wrong, and your validator shows that something is 
wrong, the situation is clear. I think those other projects don't do it 
because they're lazy, more than anything else. I can't really think of 
any negative effects from versioning. You can always allow old versions 
to work, as long as nothing is backwards incompatible, same as for 
example the web-app dtd...

But anyways, that's just my opinion. It's not the end of the world if it 
stays unversioned...  :-)


Rod Johnson wrote:

>I agree. I'm inclined to leave it as is for now.
>
>----- Original Message -----
>From: "jürgen höller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Sunday, February 22, 2004 7:58 PM
>Subject: Re: [Springframework-developer] DTD versioning
>
>
>We need a final decision here: Keep "spring-beans.dtd" for the time being,
>switch to "spring-beans-1.0.dtd", or switch to "spring-beans_1_0.dtd". In
>any case, our BeansDtdResolver is still able to resolve "spring-beans.dtd"
>for backward compatibility.
>
>As I outlined earlier, DTD compatibility doesn't seem to be a major issue
>for users. Hibernate has a version number, but just for the major release
>2.0: The modified DTD for Hibernate 2.1 still use the same file name,
>despite the "jcs-cache"/"cache" change. Ant doesn't even have a proper DTD.
>
>As a counterexample, Struts uses strict DTD versioning. However, even Tiles
>used "tiles-config.dtd" initially, switching to "tiles-config_1_1.dtd" later
>on.
>
>I've thought about this issue for quite a while now, and I'm inclined to
>leave it as "spring-beans.dtd" for the time being. We can always change to a
>versioned DTD if we feel the need to. Any final thoughts on this?
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag von
>Colin Sampaleanu
>Gesendet: Mi 18.02.2004 13:39
>An: spr...@li...
>Betreff: Re: [Springframework-developer] DTD versioning
>
>
>
>Personally I'd rather get a version number in there from the get-go,
>especially given that we've already had a few variants. I also have no
>problem with the possibility that some future release (e.g. 1.2) ships
>with a DTD which has an unchanged version number (e.g. 1.0). I consider
>it a DTD version, whos primary goal is to indicate a change from one DTD
>to another. Of course if something does change in the DTD so you change
>the DTD number for another version of the DTD, it makes sense to make
>the new version the same as the Spring version which introduces the change.
>
>But the only thing I feel pretty strongly about is chaning the version
>in the name when something actually changes, so if other people just
>want to leave the name as-is for now, I have no real objections...
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>I actually prefer the Hibernate style "spring-beans-1.0.dtd", as it seems
>>    
>>
>more natural to me. After all, underscores look like a workaround for
>filesystems that can't handle dots in filenames.
>  
>
>>An interesting point is that it could well be that our bean definition
>>    
>>
>format won't change for the next couple of Spring releases. All the new
>features that we plan to introduce are achievable with the current generic
>format. So if we recommend a versioned DTD, we have to assume that the
>"spring-beans-1.0.dtd" reference will be in use for Spring 1.1/1.2/etc too,
>arguably looking a bit odd.
>  
>
>>Hibernate is also a bit weird in that respect: "hibernate-mapping-2.0.dtd"
>>    
>>
>was modified for 2.1 but still kept the 2.0 DTD version number... Noone
>complained, so I guess most people are fine with DTDs that aren't versioned
>(respectively not versioned in a fine-grained version).
>  
>
>>So a further option for us would be to stay with "spring-beans.dtd" for as
>>    
>>
>long as there aren't any significant changes in the DTD. Of course, we would
>allow "spring-beans.dtd" as shortcut anyway, always defaulting to the most
>current DTD. The question is rather: What DTD name to we *recommend* to
>use - explicit version or not? Consequently, what DTD name will our sample
>apps use?
>  
>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf
>>Of Colin Sampaleanu
>>Sent: Tuesday, February 17, 2004 2:12 PM
>>To: spr...@li...
>>Subject: Re: Re [Springframework-developer] DTD versioning
>>
>>
>>I am ok with either one. I picked the variant I did before because it is
>>what Sun uses, but if somebody likes the Hibernate-style better I am ok
>>with that.
>>
>>jürgen höller [werk3AT] wrote:
>>
>>
>>
>>    
>>
>>>Any opinions on the exact naming of the DTD file? I'd like to commit the
>>>      
>>>
>change promptly :-)
>  
>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: spr...@li... im Auftrag von
>>>      
>>>
>jürgen höller [werk3AT]
>  
>
>>>Gesendet: Mo 16.02.2004 08:40
>>>An: spr...@li...
>>>Betreff: Re: [Springframework-developer] DTD versioning
>>>
>>>
>>>
>>>Colin, Rod,
>>>
>>>I've just adapted BeansDtdResolver to fall back to the default DTD file
>>>      
>>>
>"spring-beans_1_0.dtd" if  "spring-beans.dtd" was specified, issuing a
>corresponding message at INFO level (not committed yet). I guess INFO is
>appropriate, as "spring-beans" can simply be considered a shortcut for
>"spring-beans_1_0" for the time being.
>  
>
>>>If we agree on the exact naming that Colin proposed, I'll commit this and
>>>      
>>>
>adapt all our bean definition declarations in the samples etc. The only
>alternative that I see is "spring-beans-1.0.dtd" as used by Hibernate's
>DTDs, while "_1_0" is the style used by Sun's DTDs.
>  
>
>>>IMO, "spring-beans.dtd" should also stay available from the website,
>>>      
>>>
>simply adding the versioned DTD file there.
>  
>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: spr...@li... im Auftrag von
>>>      
>>>
>Rod Johnson
>  
>
>>>Gesendet: So 15.02.2004 17:18
>>>An: spr...@li...
>>>Betreff: Re: [Springframework-developer] DTD versioning
>>>
>>>
>>>
>>>Colin
>>>
>>>I agree about versioning, so long as we can avoid breaking people's
>>>definitions. We could have only the new URL on the web site and modify the
>>>entity resolver so that it produces a log warning on finding the old one
>>>(but still resolved it). This should provide a deprecation-style upgrade
>>>path.
>>>
>>>Regards,
>>>Rod
>>>
>>>----- Original Message -----
>>>From: "Colin Sampaleanu" <col...@ex...>
>>>To: <spr...@li...>
>>>Sent: Sunday, February 15, 2004 3:26 PM
>>>Subject: [Springframework-developer] DTD versioning
>>>
>>>
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>I updated the DTD on the website, and this reminds me that we should
>>>>version the document. I propose naming it something like
>>>>
>>>>spring-beans_1_0.dtd
>>>>
>>>>with the doctype definition being:
>>>>
>>>><!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 1.0//EN"
>>>>      "http://www.springframework.org/dtd/spring-beans_1_0.dtd">
>>>>
>>>>If everyone is in agreement, the only question is if we should keep the
>>>>old one around (ie keep both versions) for the 1.0 release. I would
>>>>favour having only the new version, to avoid future confusion, although
>>>>this would force everybody to update their definition documents.
>>>>
>>>>Regards,
>>>>Colin
>>>>
>>>>
>>>>
>>>>        
>>>>
>
>
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

Re: [Springframework-developer] DTD versioning

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

I agree. I'm inclined to leave it as is for now.

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Sunday, February 22, 2004 7:58 PM
Subject: Re: [Springframework-developer] DTD versioning


We need a final decision here: Keep "spring-beans.dtd" for the time being=
,
switch to "spring-beans-1.0.dtd", or switch to "spring-beans_1_0.dtd". In
any case, our BeansDtdResolver is still able to resolve "spring-beans.dtd=
"
for backward compatibility.

As I outlined earlier, DTD compatibility doesn't seem to be a major issue
for users. Hibernate has a version number, but just for the major release
2.0: The modified DTD for Hibernate 2.1 still use the same file name,
despite the "jcs-cache"/"cache" change. Ant doesn't even have a proper DT=
D.

As a counterexample, Struts uses strict DTD versioning. However, even Til=
es
used "tiles-config.dtd" initially, switching to "tiles-config_1_1.dtd" la=
ter
on.

I've thought about this issue for quite a while now, and I'm inclined to
leave it as "spring-beans.dtd" for the time being. We can always change t=
o a
versioned DTD if we feel the need to. Any final thoughts on this?

Juergen


________________________________

Von: spr...@li... im Auftrag von
Colin Sampaleanu
Gesendet: Mi 18.02.2004 13:39
An: spr...@li...
Betreff: Re: [Springframework-developer] DTD versioning



Personally I'd rather get a version number in there from the get-go,
especially given that we've already had a few variants. I also have no
problem with the possibility that some future release (e.g. 1.2) ships
with a DTD which has an unchanged version number (e.g. 1.0). I consider
it a DTD version, whos primary goal is to indicate a change from one DTD
to another. Of course if something does change in the DTD so you change
the DTD number for another version of the DTD, it makes sense to make
the new version the same as the Spring version which introduces the chang=
e.

But the only thing I feel pretty strongly about is chaning the version
in the name when something actually changes, so if other people just
want to leave the name as-is for now, I have no real objections...

j=FCrgen h=F6ller [werk3AT] wrote:

>I actually prefer the Hibernate style "spring-beans-1.0.dtd", as it seem=
s
more natural to me. After all, underscores look like a workaround for
filesystems that can't handle dots in filenames.
>
>An interesting point is that it could well be that our bean definition
format won't change for the next couple of Spring releases. All the new
features that we plan to introduce are achievable with the current generi=
c
format. So if we recommend a versioned DTD, we have to assume that the
"spring-beans-1.0.dtd" reference will be in use for Spring 1.1/1.2/etc to=
o,
arguably looking a bit odd.
>
>Hibernate is also a bit weird in that respect: "hibernate-mapping-2.0.dt=
d"
was modified for 2.1 but still kept the 2.0 DTD version number... Noone
complained, so I guess most people are fine with DTDs that aren't version=
ed
(respectively not versioned in a fine-grained version).
>
>So a further option for us would be to stay with "spring-beans.dtd" for =
as
long as there aren't any significant changes in the DTD. Of course, we wo=
uld
allow "spring-beans.dtd" as shortcut anyway, always defaulting to the mos=
t
current DTD. The question is rather: What DTD name to we *recommend* to
use - explicit version or not? Consequently, what DTD name will our sampl=
e
apps use?
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Tuesday, February 17, 2004 2:12 PM
>To: spr...@li...
>Subject: Re: Re [Springframework-developer] DTD versioning
>
>
>I am ok with either one. I picked the variant I did before because it is
>what Sun uses, but if somebody likes the Hibernate-style better I am ok
>with that.
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>
>
>
>>Any opinions on the exact naming of the DTD file? I'd like to commit th=
e
change promptly :-)
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag v=
on
j=FCrgen h=F6ller [werk3AT]
>>Gesendet: Mo 16.02.2004 08:40
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] DTD versioning
>>
>>
>>
>>Colin, Rod,
>>
>>I've just adapted BeansDtdResolver to fall back to the default DTD file
"spring-beans_1_0.dtd" if  "spring-beans.dtd" was specified, issuing a
corresponding message at INFO level (not committed yet). I guess INFO is
appropriate, as "spring-beans" can simply be considered a shortcut for
"spring-beans_1_0" for the time being.
>>
>>If we agree on the exact naming that Colin proposed, I'll commit this a=
nd
adapt all our bean definition declarations in the samples etc. The only
alternative that I see is "spring-beans-1.0.dtd" as used by Hibernate's
DTDs, while "_1_0" is the style used by Sun's DTDs.
>>
>>IMO, "spring-beans.dtd" should also stay available from the website,
simply adding the versioned DTD file there.
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag v=
on
Rod Johnson
>>Gesendet: So 15.02.2004 17:18
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] DTD versioning
>>
>>
>>
>>Colin
>>
>>I agree about versioning, so long as we can avoid breaking people's
>>definitions. We could have only the new URL on the web site and modify =
the
>>entity resolver so that it produces a log warning on finding the old on=
e
>>(but still resolved it). This should provide a deprecation-style upgrad=
e
>>path.
>>
>>Regards,
>>Rod
>>
>>----- Original Message -----
>>From: "Colin Sampaleanu" <col...@ex...>
>>To: <spr...@li...>
>>Sent: Sunday, February 15, 2004 3:26 PM
>>Subject: [Springframework-developer] DTD versioning
>>
>>
>>
>>
>>
>>
>>>I updated the DTD on the website, and this reminds me that we should
>>>version the document. I propose naming it something like
>>>
>>>spring-beans_1_0.dtd
>>>
>>>with the doctype definition being:
>>>
>>><!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 1.0//EN"
>>>       "http://www.springframework.org/dtd/spring-beans_1_0.dtd">
>>>
>>>If everyone is in agreement, the only question is if we should keep th=
e
>>>old one around (ie keep both versions) for the 1.0 release. I would
>>>favour having only the new version, to avoid future confusion, althoug=
h
>>>this would force everybody to update their definition documents.
>>>
>>>Regards,
>>>Colin
>>>
>>>
>>>




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] DTD versioning

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

We need a final decision here: Keep "spring-beans.dtd" for the time =
being, switch to "spring-beans-1.0.dtd", or switch to =
"spring-beans_1_0.dtd". In any case, our BeansDtdResolver is still able =
to resolve "spring-beans.dtd" for backward compatibility.
=20
As I outlined earlier, DTD compatibility doesn't seem to be a major =
issue for users. Hibernate has a version number, but just for the major =
release 2.0: The modified DTD for Hibernate 2.1 still use the same file =
name, despite the "jcs-cache"/"cache" change. Ant doesn't even have a =
proper DTD.
=20
As a counterexample, Struts uses strict DTD versioning. However, even =
Tiles used "tiles-config.dtd" initially, switching to =
"tiles-config_1_1.dtd" later on.
=20
I've thought about this issue for quite a while now, and I'm inclined to =
leave it as "spring-beans.dtd" for the time being. We can always change =
to a versioned DTD if we feel the need to. Any final thoughts on this?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Mi 18.02.2004 13:39
An: spr...@li...
Betreff: Re: [Springframework-developer] DTD versioning



Personally I'd rather get a version number in there from the get-go,
especially given that we've already had a few variants. I also have no
problem with the possibility that some future release (e.g. 1.2) ships
with a DTD which has an unchanged version number (e.g. 1.0). I consider
it a DTD version, whos primary goal is to indicate a change from one DTD
to another. Of course if something does change in the DTD so you change
the DTD number for another version of the DTD, it makes sense to make
the new version the same as the Spring version which introduces the =
change.

But the only thing I feel pretty strongly about is chaning the version
in the name when something actually changes, so if other people just
want to leave the name as-is for now, I have no real objections...

j=FCrgen h=F6ller [werk3AT] wrote:

>I actually prefer the Hibernate style "spring-beans-1.0.dtd", as it =
seems more natural to me. After all, underscores look like a workaround =
for filesystems that can't handle dots in filenames.
>
>An interesting point is that it could well be that our bean definition =
format won't change for the next couple of Spring releases. All the new =
features that we plan to introduce are achievable with the current =
generic format. So if we recommend a versioned DTD, we have to assume =
that the "spring-beans-1.0.dtd" reference will be in use for Spring =
1.1/1.2/etc too, arguably looking a bit odd.
>
>Hibernate is also a bit weird in that respect: =
"hibernate-mapping-2.0.dtd" was modified for 2.1 but still kept the 2.0 =
DTD version number... Noone complained, so I guess most people are fine =
with DTDs that aren't versioned (respectively not versioned in a =
fine-grained version).
>
>So a further option for us would be to stay with "spring-beans.dtd" for =
as long as there aren't any significant changes in the DTD. Of course, =
we would allow "spring-beans.dtd" as shortcut anyway, always defaulting =
to the most current DTD. The question is rather: What DTD name to we =
*recommend* to use - explicit version or not? Consequently, what DTD =
name will our sample apps use?
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Tuesday, February 17, 2004 2:12 PM
>To: spr...@li...
>Subject: Re: Re [Springframework-developer] DTD versioning
>
>
>I am ok with either one. I picked the variant I did before because it =
is
>what Sun uses, but if somebody likes the Hibernate-style better I am ok
>with that.
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>
>=20
>
>>Any opinions on the exact naming of the DTD file? I'd like to commit =
the change promptly :-)
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
>>Gesendet: Mo 16.02.2004 08:40
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] DTD versioning
>>
>>
>>
>>Colin, Rod,
>>
>>I've just adapted BeansDtdResolver to fall back to the default DTD =
file "spring-beans_1_0.dtd" if  "spring-beans.dtd" was specified, =
issuing a corresponding message at INFO level (not committed yet). I =
guess INFO is appropriate, as "spring-beans" can simply be considered a =
shortcut for "spring-beans_1_0" for the time being.
>>
>>If we agree on the exact naming that Colin proposed, I'll commit this =
and adapt all our bean definition declarations in the samples etc. The =
only alternative that I see is "spring-beans-1.0.dtd" as used by =
Hibernate's DTDs, while "_1_0" is the style used by Sun's DTDs.
>>
>>IMO, "spring-beans.dtd" should also stay available from the website, =
simply adding the versioned DTD file there.
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag =
von Rod Johnson
>>Gesendet: So 15.02.2004 17:18
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] DTD versioning
>>
>>
>>
>>Colin
>>
>>I agree about versioning, so long as we can avoid breaking people's
>>definitions. We could have only the new URL on the web site and modify =
the
>>entity resolver so that it produces a log warning on finding the old =
one
>>(but still resolved it). This should provide a deprecation-style =
upgrade
>>path.
>>
>>Regards,
>>Rod
>>
>>----- Original Message -----
>>From: "Colin Sampaleanu" <col...@ex...>
>>To: <spr...@li...>
>>Sent: Sunday, February 15, 2004 3:26 PM
>>Subject: [Springframework-developer] DTD versioning
>>
>>
>>
>>
>>  =20
>>
>>>I updated the DTD on the website, and this reminds me that we should
>>>version the document. I propose naming it something like
>>>
>>>spring-beans_1_0.dtd
>>>
>>>with the doctype definition being:
>>>
>>><!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 1.0//EN"
>>>       "http://www.springframework.org/dtd/spring-beans_1_0.dtd">
>>>
>>>If everyone is in agreement, the only question is if we should keep =
the
>>>old one around (ie keep both versions) for the 1.0 release. I would
>>>favour having only the new version, to avoid future confusion, =
although
>>>this would force everybody to update their definition documents.
>>>
>>>Regards,
>>>Colin
>>>
>>>    =20
>>>




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] AOP changes

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

Funny coincidence: I thought about the need for a quick RC2 release this =
weekend (even if I had a family/friends weekend ;-)
=20
If we consolidate everything promptly, a mid-week RC2 release would be =
manageable. I'll commit the one thing that I haven't yet (the "type" =
argument for the constructor-arg tag) tomorrow. Please test everything =
on Tuesday and Wednesday then; I suggest to release RC2 Wednesday night.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: So 22.02.2004 11:01
An: spr...@li...
Betreff: [Springframework-developer] AOP changes



All,

I've just committed some changes to the Advisor hierarchy, to get rid of =
the
parallel hierarchy between Advisors and Advices, which was bothering me.

Now instead of having a hierarchy of Advisors, Advisor has a getAdvice()
method that returns Object. It can't be more strongly typed because of =
AOP
Alliance compliance. Originally I think I wanted to get away from such =
weak
typing, but I'm just not happy with the old parallel class hierarchices.
There are no longer specific Advisor subclasses, like
DefaultMethodBeforeAdvisor: their's just DefaultPointcutAdvisor. An =
Advisor
has a pointcut associated with it or not.

There are quite a few fewer classes in the new approach (-17 I think). =
And
it's more flexible, as DefaultPointcutAdvisor can be reused for any =
advice
type.

The impact on user code should be quite small. If you've extended one of
those advisors, extend the appropriate generic PointcutAdvisor subclass.
RegExpMethodPointcutAdvisor now replaces the old Around advice pointcut
advisor.

The changes make it possible to reuse the regexp pointcut advisor (or =
other
pointcut advisor subclasses) for any kind of advice.

Because this is a public API change, I think we need to consider going =
RC2,
instead of straight to 1.0 now. I was strongly in favour of going =
straight
to 1.0, but there have also been some other public API changes (notably =
in
JDBC) as well as the new Quartz functionality, so I vote for a quick =
release
of RC2 (early this week) and a goal of 1.0 2 weeks after that, with NO =
more
changes except bug fixes.

Regards,
Rod




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] AOP changes

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

It shouldn't have much impact on apps. Just simple class name substitution,
from whatever to DefaultPointcutAdvisor or to RegexpMethodPointcutAdvisor.

I've also simplified the implementation of the aop.adapter package following
the earlier changes. This doesn't affect applications at all. Indeed, I
didn't change the test suite at all.

Regards,
Rod

----- Original Message -----
From: "Dmitriy Kopylenko" <dko...@ru...>
To: <spr...@li...>
Sent: Sunday, February 22, 2004 2:39 PM
Subject: Re: [Springframework-developer] AOP changes


> me too...
>
> it also means that I would need to do some refactoring on my apps... :-(
>
> ----- Original Message -----
> From: Colin Sampaleanu <col...@ex...>
> Date: Sunday, February 22, 2004 8:22 am
> Subject: Re: [Springframework-developer] AOP changes
>
> > +1 on the RC2
> >
> > Rod Johnson wrote:
> >
> > >All,
> > >
> > >I've just committed some changes to the Advisor hierarchy, to get
> > rid of the
> > >parallel hierarchy between Advisors and Advices, which was
> > bothering me.
> > >
> > >Now instead of having a hierarchy of Advisors, Advisor has a
> > getAdvice()>method that returns Object. It can't be more strongly
> > typed because of AOP
> > >Alliance compliance. Originally I think I wanted to get away from
> > such weak
> > >typing, but I'm just not happy with the old parallel class
> > hierarchices.>There are no longer specific Advisor subclasses, like
> > >DefaultMethodBeforeAdvisor: their's just DefaultPointcutAdvisor.
> > An Advisor
> > >has a pointcut associated with it or not.
> > >
> > >There are quite a few fewer classes in the new approach (-17 I
> > think). And
> > >it's more flexible, as DefaultPointcutAdvisor can be reused for
> > any advice
> > >type.
> > >
> > >The impact on user code should be quite small. If you've extended
> > one of
> > >those advisors, extend the appropriate generic PointcutAdvisor
> > subclass.>RegExpMethodPointcutAdvisor now replaces the old Around
> > advice pointcut
> > >advisor.
> > >
> > >The changes make it possible to reuse the regexp pointcut advisor
> > (or other
> > >pointcut advisor subclasses) for any kind of advice.
> > >
> > >Because this is a public API change, I think we need to consider
> > going RC2,
> > >instead of straight to 1.0 now. I was strongly in favour of going
> > straight>to 1.0, but there have also been some other public API
> > changes (notably in
> > >JDBC) as well as the new Quartz functionality, so I vote for a
> > quick release
> > >of RC2 (early this week) and a goal of 1.0 2 weeks after that,
> > with NO more
> > >changes except bug fixes.
> > >
> > >Regards,
> > >Rod
> > >
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > Build and deploy apps & Web services for Linux with
> > a free DVD software kit from IBM. Click Now!
> > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] AOP changes

[Dmitriy K. <dko...@ru...>]

me too...

it also means that I would need to do some refactoring on my apps... :-(

----- Original Message -----
From: Colin Sampaleanu <col...@ex...>
Date: Sunday, February 22, 2004 8:22 am
Subject: Re: [Springframework-developer] AOP changes

> +1 on the RC2
> 
> Rod Johnson wrote:
> 
> >All,
> >
> >I've just committed some changes to the Advisor hierarchy, to get 
> rid of the
> >parallel hierarchy between Advisors and Advices, which was 
> bothering me.
> >
> >Now instead of having a hierarchy of Advisors, Advisor has a 
> getAdvice()>method that returns Object. It can't be more strongly 
> typed because of AOP
> >Alliance compliance. Originally I think I wanted to get away from 
> such weak
> >typing, but I'm just not happy with the old parallel class 
> hierarchices.>There are no longer specific Advisor subclasses, like
> >DefaultMethodBeforeAdvisor: their's just DefaultPointcutAdvisor. 
> An Advisor
> >has a pointcut associated with it or not.
> >
> >There are quite a few fewer classes in the new approach (-17 I 
> think). And
> >it's more flexible, as DefaultPointcutAdvisor can be reused for 
> any advice
> >type.
> >
> >The impact on user code should be quite small. If you've extended 
> one of
> >those advisors, extend the appropriate generic PointcutAdvisor 
> subclass.>RegExpMethodPointcutAdvisor now replaces the old Around 
> advice pointcut
> >advisor.
> >
> >The changes make it possible to reuse the regexp pointcut advisor 
> (or other
> >pointcut advisor subclasses) for any kind of advice.
> >
> >Because this is a public API change, I think we need to consider 
> going RC2,
> >instead of straight to 1.0 now. I was strongly in favour of going 
> straight>to 1.0, but there have also been some other public API 
> changes (notably in
> >JDBC) as well as the new Quartz functionality, so I vote for a 
> quick release
> >of RC2 (early this week) and a goal of 1.0 2 weeks after that, 
> with NO more
> >changes except bug fixes.
> >
> >Regards,
> >Rod
> >  
> >
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] AOP changes

[<tri...@tr...>]

> Because this is a public API change, I think we need to consider going RC2,
> instead of straight to 1.0 now. I was strongly in favour of going straight
> to 1.0, but there have also been some other public API changes (notably in
> JDBC) as well as the new Quartz functionality, so I vote for a quick release
> of RC2 (early this week) and a goal of 1.0 2 weeks after that, 

+1

> with NO more
> changes except bug fixes.
> 

:-)

Thomas

Re: [Springframework-developer] I would like to remove JdbcTemplate/JdbcAccessor eager init of exception translator

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

Hmm, too bad.   The problem is that if you can get your hands on the 
database name, which is something that you would never want to hard-code 
in your code, then you can probably also just get your hands on a 
jdbcTemplate instance from the context, used as a singleton.   I was 
hoping to just make 'new jdbcTemplate(datasource)' as efficient as that 
approach...


tri...@tr... wrote:

>Colin,
>
>I think Rod did make it lazy init at some point, but the problem was that some
>jdbc driver (I think MS SQL Server) was not letting us use the connection after
>some exception was thrown.  This prevented us from loading the meta data and the
>translation mapping.  
>
>All we really need is the database product name, so if you
>could set that explicitly, then we don't need to look it up.  
>
>There is already code in SQLErrorCodesFactory to avoid the database metadata
>lookup if you pass in a database product name.
>
>  public SQLErrorCodes getErrorCodes(String dbName)
>
>I think all you need now is to do is create a custom 
>SQLErrorCodeSQLExceptionTranslator where you set the database product name
>explicitly and load the error codes using this rather than the data source.
>
>Thomas
>
>
>
>Quoting Colin Sampaleanu <col...@ex...>:
>
>  
>
>>I've been sitting here all day watching logs go by as I try to get a 
>>system into production, and seeing a lot of pauses as the
>>  new JdbcTemplate(dataSource)
>>in JdbcHelper causes, every single time JdbcHelper is created, the 
>>exception metadata to be pulled from the DB.
>>
>>Now this is code using Spring slightly post RC1. I realize JdbcHelper 
>>has gone away, but the same thing happens of course when you just do a 
>>'new JdbcTemplate(dataSource)' directly.
>>
>>I don't know why JdbcAccessor (and hence JdbcTemplate) really needs to 
>>eager init the exception translator. The access method is synchronized, 
>>so there should be no issues letting it lazy init.
>>
>>I would like to remove this eager init (in afterPropertiesSet()) of the 
>>exception translator. Please let me know if you have a problem with 
>>this. I was thinking that if somebody wants to still allow it to be 
>>eagerly inited, for the case where JdbcTemplate is coming out of a 
>>beanfactory/context then we can add a 'lazyInitExceptionTranslator' 
>>property, which would default to true.
>>
>>Regards,
>>Colin
>>
>>    
>>

Re: [Springframework-developer] AOP changes

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

+1 on the RC2

Rod Johnson wrote:

>All,
>
>I've just committed some changes to the Advisor hierarchy, to get rid of the
>parallel hierarchy between Advisors and Advices, which was bothering me.
>
>Now instead of having a hierarchy of Advisors, Advisor has a getAdvice()
>method that returns Object. It can't be more strongly typed because of AOP
>Alliance compliance. Originally I think I wanted to get away from such weak
>typing, but I'm just not happy with the old parallel class hierarchices.
>There are no longer specific Advisor subclasses, like
>DefaultMethodBeforeAdvisor: their's just DefaultPointcutAdvisor. An Advisor
>has a pointcut associated with it or not.
>
>There are quite a few fewer classes in the new approach (-17 I think). And
>it's more flexible, as DefaultPointcutAdvisor can be reused for any advice
>type.
>
>The impact on user code should be quite small. If you've extended one of
>those advisors, extend the appropriate generic PointcutAdvisor subclass.
>RegExpMethodPointcutAdvisor now replaces the old Around advice pointcut
>advisor.
>
>The changes make it possible to reuse the regexp pointcut advisor (or other
>pointcut advisor subclasses) for any kind of advice.
>
>Because this is a public API change, I think we need to consider going RC2,
>instead of straight to 1.0 now. I was strongly in favour of going straight
>to 1.0, but there have also been some other public API changes (notably in
>JDBC) as well as the new Quartz functionality, so I vote for a quick release
>of RC2 (early this week) and a goal of 1.0 2 weeks after that, with NO more
>changes except bug fixes.
>
>Regards,
>Rod
>  
>

Re: [Springframework-developer] old spring jar's

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

On Sunday 22 February 2004 11:32, Rod Johnson wrote:
> Darren
>
> Just download from SF.

ok.  It was just the compiled spring.jar I needed.  Grabbing the d/l files 
from SF is about a 50Mb d/l for the 1.0-m? releases.  Just me being lazy 
really ;-)

-- 

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

Re: [Springframework-developer] old spring jar's

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

Darren

Just download from SF.

Regards,
Rod

----- Original Message -----
From: "Darren Davison" <da...@da...>
To: <spr...@li...>
Sent: Sunday, February 22, 2004 11:07 AM
Subject: [Springframework-developer] old spring jar's


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

does anyone happen to have spring.jar files lying around built from earlier
releases?  Particularly need 1.0-m4 and 1.0-m3 just now for some testing
(back to m1 would also be handy).

It would just save me a lot of time checking out and building from cvs if
someone already has them.  Please mail them direct (not to the list) if you
have them.

Many thanks,
- --

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAOI18KLMLAN01aw0RAgddAJsFz4hv4tw2PwDPPssJ53KkVeS9ZwCZATI1
2ZIX9HnHZV8Z1hl0rLPV8q4=
=Yt5+
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id56&alloc_id438&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] old spring jar's

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

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

does anyone happen to have spring.jar files lying around built from earlier=
=20
releases?  Particularly need 1.0-m4 and 1.0-m3 just now for some testing=20
(back to m1 would also be handy).

It would just save me a lot of time checking out and building from cvs if=20
someone already has them.  Please mail them direct (not to the list) if you=
=20
have them.

Many thanks,
=2D --=20

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAOI18KLMLAN01aw0RAgddAJsFz4hv4tw2PwDPPssJ53KkVeS9ZwCZATI1
2ZIX9HnHZV8Z1hl0rLPV8q4=3D
=3DYt5+
=2D----END PGP SIGNATURE-----

[Springframework-developer] AOP changes

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

All,

I've just committed some changes to the Advisor hierarchy, to get rid of the
parallel hierarchy between Advisors and Advices, which was bothering me.

Now instead of having a hierarchy of Advisors, Advisor has a getAdvice()
method that returns Object. It can't be more strongly typed because of AOP
Alliance compliance. Originally I think I wanted to get away from such weak
typing, but I'm just not happy with the old parallel class hierarchices.
There are no longer specific Advisor subclasses, like
DefaultMethodBeforeAdvisor: their's just DefaultPointcutAdvisor. An Advisor
has a pointcut associated with it or not.

There are quite a few fewer classes in the new approach (-17 I think). And
it's more flexible, as DefaultPointcutAdvisor can be reused for any advice
type.

The impact on user code should be quite small. If you've extended one of
those advisors, extend the appropriate generic PointcutAdvisor subclass.
RegExpMethodPointcutAdvisor now replaces the old Around advice pointcut
advisor.

The changes make it possible to reuse the regexp pointcut advisor (or other
pointcut advisor subclasses) for any kind of advice.

Because this is a public API change, I think we need to consider going RC2,
instead of straight to 1.0 now. I was strongly in favour of going straight
to 1.0, but there have also been some other public API changes (notably in
JDBC) as well as the new Quartz functionality, so I vote for a quick release
of RC2 (early this week) and a goal of 1.0 2 weeks after that, with NO more
changes except bug fixes.

Regards,
Rod

Re: [Springframework-developer] I would like to remove JdbcTemplate/JdbcAccessor eager init of exception translator

[<tri...@tr...>]

Colin,

I think Rod did make it lazy init at some point, but the problem was that some
jdbc driver (I think MS SQL Server) was not letting us use the connection after
some exception was thrown.  This prevented us from loading the meta data and the
translation mapping.  

All we really need is the database product name, so if you
could set that explicitly, then we don't need to look it up.  

There is already code in SQLErrorCodesFactory to avoid the database metadata
lookup if you pass in a database product name.

  public SQLErrorCodes getErrorCodes(String dbName)

I think all you need now is to do is create a custom 
SQLErrorCodeSQLExceptionTranslator where you set the database product name
explicitly and load the error codes using this rather than the data source.

Thomas



Quoting Colin Sampaleanu <col...@ex...>:

> I've been sitting here all day watching logs go by as I try to get a 
> system into production, and seeing a lot of pauses as the
>   new JdbcTemplate(dataSource)
> in JdbcHelper causes, every single time JdbcHelper is created, the 
> exception metadata to be pulled from the DB.
> 
> Now this is code using Spring slightly post RC1. I realize JdbcHelper 
> has gone away, but the same thing happens of course when you just do a 
> 'new JdbcTemplate(dataSource)' directly.
> 
> I don't know why JdbcAccessor (and hence JdbcTemplate) really needs to 
> eager init the exception translator. The access method is synchronized, 
> so there should be no issues letting it lazy init.
> 
> I would like to remove this eager init (in afterPropertiesSet()) of the 
> exception translator. Please let me know if you have a problem with 
> this. I was thinking that if somebody wants to still allow it to be 
> eagerly inited, for the case where JdbcTemplate is coming out of a 
> beanfactory/context then we can add a 'lazyInitExceptionTranslator' 
> property, which would default to true.
> 
> Regards,
> Colin
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

[Springframework-developer] I would like to remove JdbcTemplate/JdbcAccessor eager init of exception translator

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

I've been sitting here all day watching logs go by as I try to get a 
system into production, and seeing a lot of pauses as the
  new JdbcTemplate(dataSource)
in JdbcHelper causes, every single time JdbcHelper is created, the 
exception metadata to be pulled from the DB.

Now this is code using Spring slightly post RC1. I realize JdbcHelper 
has gone away, but the same thing happens of course when you just do a 
'new JdbcTemplate(dataSource)' directly.

I don't know why JdbcAccessor (and hence JdbcTemplate) really needs to 
eager init the exception translator. The access method is synchronized, 
so there should be no issues letting it lazy init.

I would like to remove this eager init (in afterPropertiesSet()) of the 
exception translator. Please let me know if you have a problem with 
this. I was thinking that if somebody wants to still allow it to be 
eagerly inited, for the case where JdbcTemplate is coming out of a 
beanfactory/context then we can add a 'lazyInitExceptionTranslator' 
property, which would default to true.

Regards,
Colin

RE: [Springframework-developer] Spring sub-projects

[Keith D. <kd...@cs...>]

I agree, I think use of 'rcp' works just as well as 'orm', 'dao', 'ejb', =
or
'aop.'  After thinking about it for a couple of days and considering the
various points I do recommend 'spring-rcp' for the name of the module.  =
I
recommend org.springframework.rcp as the package name, and =
spring-rcp.jar as
the jar file name.  It's consistent and concise, and we do have the =
benefit
of the acronym catching on in the industry.

I will make sure to thoroughly document what 'rcp' standard for (Rich =
Client
Platform) and I'm sure we'll use the full name when referring to the
project--something like "check out Spring's new Rich Client Platform
(RCP)..." when marketing it.

Coming up with names is never easy! I remember one project I was on
marketing came up with the name "Assurity" - we on the team all =
immediately
noticed what that as a three letter acronym spelled! :-) Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: Tuesday, February 17, 2004 11:52 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Spring sub-projects


But doesn't the sample apply to terms like DAO, ORM, or AOP? We're =
happily
using those too...


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf =
Of
Francois Beausoleil
Sent: Tuesday, February 17, 2004 5:26 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Spring sub-projects


Hi !

Sorry for jumping on the bandwagon, but:

RCP =3D Rich Client Project

       or

RCP =3D Remotely Callable Procedure

       or

RCP =3D Rendering Capable Computer

TLAs (Three-Letter-Acronyms) are certainly cool, but they don't say =
much...
I would prefer richclient, but my vote is certainly non-binding.  =
Besides,
most people use an IDE, and the IDE is responsible for typing many =
things
up.  The only place where this is an issue is in the XML configuration
files, and Idea is capable of using Ctrl+Space to navigate the usual =
package
hierarchy.

My 2 cents...

Bye !
Fran=E7ois

On Tue, 17 Feb 2004 10:55:15 -0500, "Keith Donald" <kd...@cs...>
said:
> So we could have:
>=20
> #1
> spring-rcp.jar
> spring-rcp as the CVS module
> org.springframework.rcp.*
>=20
> [or]
>=20
> #2
> spring-richclient.jar
> spring-richclient as the CVS module
> org.springframework.richclient.*
>=20
> I'm torn. rcp is a bit cryptic but it is less typing and the acronym
> to me has a certain cool factor.  I'd be happy to work with either. =20
> Keith
>=20
> ----- Original Message -----
> From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> To: <spr...@li...>
> Sent: Tuesday, February 17, 2004 10:18 AM
> Subject: RE: [Springframework-developer] Spring sub-projects
>=20
>=20
> > I'd like to keep the module name somewhat in sync with the package
> > and jar
> file name. I don't really see the point in calling the package "rcp"
> but the module "rich-client".
> >
> > Juergen
> >
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]On
> > Behalf Of Keith Donald
> > Sent: Tuesday, February 17, 2004 4:01 PM
> > To: spr...@li...
> > Subject: Re: [Springframework-developer] Spring sub-projects
> >
> >
> > I'm fine with 'spring-rich-client' as the module name... the main
> > reason I suggested 'spring-rcp' initially was to be consistent with=20
> > the proposed package name: org.springframework.rcp (to me
> org.springframework.richclient
> > seemed a little wordy.)
> >
> > 'rcp' also seems to be a buzzing acronym these days, not that I am
> > big
> into
> > buzzwords or anything (although  I do have a business degree. :-))
> > Keith
> >
> > ----- Original Message -----
> > From: "Kopylenko, Dmitry" <dko...@su...>
> > To: <spr...@li...>
> > Sent: Tuesday, February 17, 2004 8:09 AM
> > Subject: RE: [Springframework-developer] Spring sub-projects
> >
> >
> > > Well, spring-rcp is a bit cryptic. How about spring-rich-client?
> > >
> > > -----Original Message-----
> > > From: j=FCrgen h=F6ller [werk3AT] =
[mailto:jue...@we...]
> > > Sent: Tuesday, February 17, 2004 8:04 AM
> > > To: spr...@li...
> > > Subject: RE: [Springframework-developer] Spring sub-projects
> > >
> > >
> > > Any opinions regarding the new module names? Else, I'll create
> > "spring-rcp"
> > > and "spring-eclipse" in the course of this week.
> > >
> > > Juergen
> > >
> > >
> > > -----Original Message-----
> > > From: spr...@li...
> > > [mailto:spr...@li...]On
> > > Behalf
> Of
> > > j=FCrgen h=F6ller [werk3AT]
> > > Sent: Monday, February 16, 2004 9:59 AM
> > > To: spr...@li...
> > > Subject: [Springframework-developer] Spring sub-projects
> > >
> > >
> > > Everybody,
> > >
> > > As recently discussed in private mails, I suggest to keep
> > > sub-projects
> > that
> > > are close to the Spring core as separate modules in Spring's main
> > > CVS.
> The
> > > first two candidates are:
> > >
> > > - Keith Donald's Spring Rich Client Platform
> > > - Torsten Juergeleit's Spring Eclipse Plugin
> > >
> > > Both Keith and Torsten are in favor of hosting them in our main
> > > CVS. So
> if
> > > noone objects, I will create new CVS modules "spring-rcp" and
> > > "spring-eclipse", and accordingly give Keith and Torsten commit=20
> > > rights
> for
> > > the main CVS. As the module names cannot be changed easily, feel
> > > free to suggest different names!
> > >
> > > The rationale is to keep all projects that use
> > > "org.springframework" as package name in Spring's main CVS.=20
> > > Separate modules make sense to let
> the
> > > sub-projects evolve independently; this way, they do not have to
> > > be
> > released
> > > in direct accordance with the Spring core. Of course, generic
> > > classes
> that
> > > emerge can still go into the core.
> > >
> > > Consequently, both sub-projects should also get respective
> > > sections on
> our
> > > main website. We should definitely clarify all this before 1.0
> > > final
> > (March
> > > 1st), as I expect quite a lot of media coverage at that time - we
> > shouldn't
> > > miss that chance!
> > >
> > > Juergen
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and
> > > deploy apps & Web services for Linux with a free DVD software kit=20
> > > from IBM. Click Now!=20
> > > http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
> > > _______________________________________________
> > > Springframework-developer mailing list=20
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-devel
> > > oper
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and
> > > deploy apps & Web services for Linux with a free DVD software kit=20
> > > from IBM. Click Now!=20
> > > http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
> > > _______________________________________________
> > > Springframework-developer mailing list=20
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-devel
> > > oper
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and
> > > deploy apps & Web services for Linux with a free DVD software kit=20
> > > from IBM. Click Now!=20
> > > http://ads.osdn.com/?ad_id=1356&alloc_id438&op=CCk
> > > _______________________________________________
> > > Springframework-developer mailing list=20
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-devel
> > > oper
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and
> > deploy apps & Web services for Linux with a free DVD software kit=20
> > from IBM. Click Now!=20
> > http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
> > _______________________________________________
> > Springframework-developer mailing list=20
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-develop
> > er
> >
> >
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and
> > deploy apps & Web services for Linux with a free DVD software kit=20
> > from IBM. Click Now! =
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=CCk
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and
> deploy apps & Web services for Linux with a free DVD software kit from =

> IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
Developer of Java Gui Builder
http://jgb.sourceforge.net/


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=CCk
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Idea for Spring HttpServlet and F ilter beans

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

Cameron,
 
the similar functionality you described is already implemented by Spring's
HttpServletBean. Here is the JavaDoc description:
 
Simple extension of javax.servlet.http.HttpServlet that treats its config
parameters as bean properties. A very handy superclass for any type of
servlet.

Type conversion is automatic. It is also possible for subclasses to specify
required properties.

This servlet leaves request handling to subclasses, inheriting the default
behaviour of HttpServlet.

This servlet superclass has no dependency on the application context

 

Regards,

Dmitriy.

 

-----Original Message-----
From: Cameron Braid [mailto:ca...@da...] 
Sent: Friday, February 20, 2004 1:31 AM
To: spr...@li...
Subject: [Springframework-developer] Idea for Spring HttpServlet and Filter
beans


I don't use spring mvc, so this idea may already be implemented.
 
The pattern goes something like this :
 
Have a SpringBeanDelegatingServlet and a SpringBeanDelegatingFilter class
that implement HttpServlet and Filter respectively.
 
These classes use init-params to define a named bean to delegate to within
spring.
 

Their process methods (process(request,response) or
filter(request,response,chain)) delegate to this bean within spring.
 
This allows the beans witin spring to implement HttpServlet or Filter, and
to be configured using normal bean configuration like any other bean.
 
I presume that something like this is already integrated into the MVC
portion of spring, but I would like to have these two standalone classes to
be able to write my own servlets that don't use any other parts of the mcv
system.
 
Thanks,
 
Cameron.

[Springframework-developer] NestingMessageSource -> HierarchicalMessageSource

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

On the occasion of the ReloadableResourceBundleMessageSource question on =
the user mailing list: Why is our hierarchical MessageSource called =
"NestingMessageSource" when our hierarchical BeanFactory is called =
"HierarchicalBeanFactory"?
=20
I suggest to renamed NestingMessageSource to =
"HierarchicalMessageSource", and AbstractNestingMessageSource to =
AbstractMessageSource (analogous to AbstractBeanFactory). Accordingly, =
NestingThemeSource should be called "HierarchicalThemeSource".
=20
I'd also like to remove the AbstractXmlUiApplicationContext and =
StaticUiApplicationContext base classes: All they do is invoke =
UiApplicationContextUtils.initThemeSource. I'd like to put those calls =
in the concrete ApplicationContext implementations, like =
XmlWebApplicationContext.
=20
Hardly any applications will be affected by those changes, as this is =
all managed under the hood by the application context implementations.
=20
Juergen