springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Spring forum down!

[Matthew E. P. <mat...@me...>]

Ross:
   We (Contegix) host the server.  I am not seeing this message now. =20
Are you?


Cheers,
   Matthew

On Apr 20, 2005, at 2:58 AM, Mason, Ross wrote:

> Hey guys,
> =A0
> I'm getting a 404 on http://forum.springframework.org/
> =A0
> Ross

[Springframework-developer] Spring forum down!

[Mason, R. <ros...@vi...>]

Hey guys,
=20
I'm getting a 404 on http://forum.springframework.org/
=20
Ross

Re: [Springframework-developer] OpenSessionInView and portlet support

[J. E. R. <er...@di...>]

Hi,

A Portlet is not a Servlet, a set of portlets are invoked directly by 
the portlet-container in one client request.

The portlet spec says: "If the client request is triggered by an action 
URL, the portal/portlet-container must first trigger the action request 
by invoking the processAction method of the targeted portlet. The 
portal/portlet-container must wait until the action request finishes. 
Then, the portal/portlet-container must trigger the render request by 
invoking the render method for all the portlets in the portal page with 
the possible exception of portlets for which their content is being 
cached. The render requests may be executed sequentially or in parallel 
without any guaranteed order."

Note that 'the render request may be executed IN PARALLEL', as I 
understand it, each render request could be executed on different 
threads. I think this feature advises against the use of 
OpenSessionInViewFilter class with portlets.

>Well, if OpenSessionInViewFilter doesn't kick in for portlets, no other
>filter will kick in with portlets either. Isn't there maybe some general
>issue hiding there?
>
>Of course we can provide an OpenSessionInViewInterceptor for portlets, but
>I'm not sure whether that's actually a good fit there. The Portlet request
>flow with separate handle and render callbacks makes this less compelling.
>
>What we certainly can't do is let the existing OpenSessionInViewInterceptor
>implement some PortletControllerInterceptor interface. That would force
>every Servlet user to have the portlet.jar on the classpath.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Erwin Vervaet
>Sent: Tuesday, April 19, 2005 9:26 PM
>To: spr...@li...
>Subject: [Springframework-developer] OpenSessionInView and portlet
>support
>
>
>Apparently the existing OSIV filter does not work with portlets:
>
>http://forum.springframework.org/viewtopic.php?t=4907
>
>I guess we should tackle this issue when doing the Portlet support for 1.3.
>There is no PortletMVC category in JIRA so I'm not sure where to file it...
>Any input from the Porlet people?
>
>Erwin Vervaet
>erw...@er...
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: New Crystal Reports XI.
>Version 11 adds new functionality designed to reduce time involved in
>creating, integrating, and deploying reporting solutions. Free runtime info,
>new features, or free trial, at: http://www.businessobjects.com/devxi/728
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: New Crystal Reports XI.
>Version 11 adds new functionality designed to reduce time involved in
>creating, integrating, and deploying reporting solutions. Free runtime info,
>new features, or free trial, at: http://www.businessobjects.com/devxi/728
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>  
>


-- 
J.Enrique Ruiz
Director de I+D+I - DiSiD S.L.L. (http://www.disid.com)
Tel +34 655 407 965
Email: er...@di...

Re: [Springframework-developer] Spring 1.2 RC2 and Acegi Security

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

This reminds me that Spring 1.2 is probably the appropriate time for 
Acegi's FilterToBeanProxy to move over from Acegi to Spring. While I 
know we deferred on this before because you had some concerns about 
lifecycle owneship, in practice the class is very useful, and it (or 
something like it) really belongs in Spring...

Colin

Juergen Hoeller wrote:

>Yes, there are essentially these two options: either require Spring 1.2 as
>of the next Acegi release (which should probably be called 0.9 then), or
>copy the old PathMatcher over. In the former case, Acegi should follow the
>new Spring pattern there: components that need path-matching functionality
>receive a PathMatcher implementation through dependency injection, using an
>AntPathMatcher as default.
>
>BTW, it would be good to unify the codebases in the mid term, for example
>moving some of the generic Acegi utility stuff over to the main Spring
>codebase. IMO, we should do this for Acegi Security 1.0 at the latest, with
>Acegi concentrating on the actual security support only. In any case, I
>guess it's inevitable to depend on a specific Spring release level at some
>point.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Andy Depue
>Sent: Tuesday, April 19, 2005 10:52 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Spring 1.2 RC2 and Acegi
>Security
>
>
>I should note that I ran across this earlier and posted a patch to the Acegi
>developer's list (see
>http://article.gmane.org/gmane.comp.java.springframework.acegisecurity.devel
>/864 ).
>I didn't officially submit this patch, as it breaks backward compatibility
>with Spring (it will only run with the very latest Spring).  If a goal of
>the
>Acegi project is to maintain such compability, it will probably either want
>to remove the dependency (by copying the code into the Acegi project), or
>use
>reflection or other technique at runtime to dynamically adapt to the Spring
>version.
>
>  - Andy
>
>On Tuesday 19 April 2005 12:11 pm, Juergen Hoeller wrote:
>  
>
>>Hi Ben,
>>
>>as Matt has noticed, there is a change in Spring 1.2 RC2 that breaks Acegi
>>Security:
>>
>><matt>
>>It's cool to see that the Spring Team has released 1.2 RC2, but there's a
>>change that causes Acegi Security (v0.8.1) to fail.
>>
>>• refactored static PathMatcher class into PathMatcher interface and
>>AntPathMatcher implementation
>>
>>This change seems to cause this issue with Acegi Security. Right now, I
>>have Spring 1.2 RC1 and Hibernate 3.0.1 bundled into AppFuse 1.8. I was
>>hoping to upgrade to Spring 1.2 RC2, but it doesn't look like this will
>>work - unless the Acegi Team releases a new version that supports 1.2 RC2
>>(hint, hint ;-). </matt>
>>
>>I've refactored the static PathMatcher into a PathMatcher interface and
>>AntPathMatcher implementation class, after repeated questions in that
>>respect. I must admit I haven't really considered that other *libraries*
>>might access that code, just that users might.
>>
>>Hence, I've accepted the tradeoff of backwards-incompatibility for 1.2,
>>because it's easy enough for users to migrate affected code - and the
>>utilities in Spring's util package are considered somewhat for internal
>>    
>>
>use
>  
>
>>in the first place. But unfortunately, there's the issue of collaborating
>>libraries...
>>
>>Anyway, I would like to keep the refactored PathMatcher, so I'd like to
>>encourage you to release an Acegi update release (0.8.2?) at your earliest
>>convenience, ideally alongside Spring 1.2 final (in about two weeks) or
>>earlier. Users should have a fully working combo then again.
>>
>>Sorry for the inconveniences caused,
>>
>>Juergen
>>    
>>

Re: [Springframework-developer] Spring 1.2 RC2 and Acegi Security

[Mark St G. <stg...@ca...>]

Hi Luke / Ben

Any idea when an official  0.9 or 0.8.2 Acegi build will be planned...
(I assume in the next few weeks to coincide with the Spring 1.2 release ?)

Cheers
Mark



                                                                           
             Luke Taylor                                                   
             <negaton@freesurf                                             
             .ch>                                                       To 
             Sent by:                  spr...@li... 
             springframework-d         rceforge.net                        
             eveloper-admin@li                                          cc 
             sts.sourceforge.n                                             
             et                                                    Subject 
                                       Re: [Springframework-developer]     
                                       Spring 1.2 RC2 and Acegi Security   
             04/19/2005 05:30                                              
             PM                                                            
                                                                           
                                                                           
             Please respond to                                             
             springframework-d                                             
                 eveloper                                                  
                                                                           
                                                                           




Hi,

I discussed this with Ben the other night and the Acegi Maven build is
now building against a Spring daily snapshot (generated by the Spring
Maven build) so any inconsistencies will hopefully be detected right away.

I modified the Acegi code earlier today to use an explicit
AntPathMatcher to get the build working again. I don't think Ben will
have any worries about requiring Spring 1.2 for the next release but it
should be easy to accomodate either way.

Luke.

Juergen Hoeller wrote:
> Yes, there are essentially these two options: either require Spring 1.2
as
> of the next Acegi release (which should probably be called 0.9 then), or
> copy the old PathMatcher over. In the former case, Acegi should follow
the
> new Spring pattern there: components that need path-matching
functionality
> receive a PathMatcher implementation through dependency injection, using
an
> AntPathMatcher as default.
>
> BTW, it would be good to unify the codebases in the mid term, for example
> moving some of the generic Acegi utility stuff over to the main Spring
> codebase. IMO, we should do this for Acegi Security 1.0 at the latest,
with
> Acegi concentrating on the actual security support only. In any case, I
> guess it's inevitable to depend on a specific Spring release level at
some
> point.
>
> Juergen
>
>


--
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk


-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime
info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] spring build.249 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050420001606Lbuild.249

Re: [Springframework-developer] Spring 1.2 RC2 and Acegi Security

[Luke T. <ne...@fr...>]

Hi,

I discussed this with Ben the other night and the Acegi Maven build is 
now building against a Spring daily snapshot (generated by the Spring 
Maven build) so any inconsistencies will hopefully be detected right away.

I modified the Acegi code earlier today to use an explicit 
AntPathMatcher to get the build working again. I don't think Ben will 
have any worries about requiring Spring 1.2 for the next release but it 
should be easy to accomodate either way.

Luke.

Juergen Hoeller wrote:
> Yes, there are essentially these two options: either require Spring 1.2 as
> of the next Acegi release (which should probably be called 0.9 then), or
> copy the old PathMatcher over. In the former case, Acegi should follow the
> new Spring pattern there: components that need path-matching functionality
> receive a PathMatcher implementation through dependency injection, using an
> AntPathMatcher as default.
> 
> BTW, it would be good to unify the codebases in the mid term, for example
> moving some of the generic Acegi utility stuff over to the main Spring
> codebase. IMO, we should do this for Acegi Security 1.0 at the latest, with
> Acegi concentrating on the actual security support only. In any case, I
> guess it's inevitable to depend on a specific Spring release level at some
> point.
> 
> Juergen
> 
> 


-- 
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk

Re: [Springframework-developer] Spring 1.2 RC2 and Acegi Security

[Juergen H. <ju...@in...>]

Yes, there are essentially these two options: either require Spring 1.2 as
of the next Acegi release (which should probably be called 0.9 then), or
copy the old PathMatcher over. In the former case, Acegi should follow the
new Spring pattern there: components that need path-matching functionality
receive a PathMatcher implementation through dependency injection, using an
AntPathMatcher as default.

BTW, it would be good to unify the codebases in the mid term, for example
moving some of the generic Acegi utility stuff over to the main Spring
codebase. IMO, we should do this for Acegi Security 1.0 at the latest, with
Acegi concentrating on the actual security support only. In any case, I
guess it's inevitable to depend on a specific Spring release level at some
point.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Andy Depue
Sent: Tuesday, April 19, 2005 10:52 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Spring 1.2 RC2 and Acegi
Security


I should note that I ran across this earlier and posted a patch to the Acegi
developer's list (see
http://article.gmane.org/gmane.comp.java.springframework.acegisecurity.devel
/864 ).
I didn't officially submit this patch, as it breaks backward compatibility
with Spring (it will only run with the very latest Spring).  If a goal of
the
Acegi project is to maintain such compability, it will probably either want
to remove the dependency (by copying the code into the Acegi project), or
use
reflection or other technique at runtime to dynamically adapt to the Spring
version.

  - Andy

On Tuesday 19 April 2005 12:11 pm, Juergen Hoeller wrote:
> Hi Ben,
>
> as Matt has noticed, there is a change in Spring 1.2 RC2 that breaks Acegi
> Security:
>
> <matt>
> It's cool to see that the Spring Team has released 1.2 RC2, but there's a
> change that causes Acegi Security (v0.8.1) to fail.
>
> • refactored static PathMatcher class into PathMatcher interface and
> AntPathMatcher implementation
>
> This change seems to cause this issue with Acegi Security. Right now, I
> have Spring 1.2 RC1 and Hibernate 3.0.1 bundled into AppFuse 1.8. I was
> hoping to upgrade to Spring 1.2 RC2, but it doesn't look like this will
> work - unless the Acegi Team releases a new version that supports 1.2 RC2
> (hint, hint ;-). </matt>
>
> I've refactored the static PathMatcher into a PathMatcher interface and
> AntPathMatcher implementation class, after repeated questions in that
> respect. I must admit I haven't really considered that other *libraries*
> might access that code, just that users might.
>
> Hence, I've accepted the tradeoff of backwards-incompatibility for 1.2,
> because it's easy enough for users to migrate affected code - and the
> utilities in Spring's util package are considered somewhat for internal
use
> in the first place. But unfortunately, there's the issue of collaborating
> libraries...
>
> Anyway, I would like to keep the refactored PathMatcher, so I'd like to
> encourage you to release an Acegi update release (0.8.2?) at your earliest
> convenience, ideally alongside Spring 1.2 final (in about two weeks) or
> earlier. Users should have a fully working combo then again.
>
> Sorry for the inconveniences caused,
>
> Juergen
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: New Crystal Reports XI.
> Version 11 adds new functionality designed to reduce time involved in
> creating, integrating, and deploying reporting solutions. Free runtime
> info, new features, or free trial, at:
> http://www.businessobjects.com/devxi/728
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring 1.2 RC2 and Acegi Security

[Andy D. <an...@ma...>]

I should note that I ran across this earlier and posted a patch to the Aceg=
i=20
developer's list (see=20
http://article.gmane.org/gmane.comp.java.springframework.acegisecurity.deve=
l/864 ). =20
I didn't officially submit this patch, as it breaks backward compatibility=
=20
with Spring (it will only run with the very latest Spring).  If a goal of t=
he=20
Acegi project is to maintain such compability, it will probably either want=
=20
to remove the dependency (by copying the code into the Acegi project), or u=
se=20
reflection or other technique at runtime to dynamically adapt to the Spring=
=20
version.

  - Andy

On Tuesday 19 April 2005 12:11 pm, Juergen Hoeller wrote:
> Hi Ben,
>
> as Matt has noticed, there is a change in Spring 1.2 RC2 that breaks Acegi
> Security:
>
> <matt>
> It's cool to see that the Spring Team has released 1.2 RC2, but there's a
> change that causes Acegi Security (v0.8.1) to fail.
>
> =95 refactored static PathMatcher class into PathMatcher interface and
> AntPathMatcher implementation
>
> This change seems to cause this issue with Acegi Security. Right now, I
> have Spring 1.2 RC1 and Hibernate 3.0.1 bundled into AppFuse 1.8. I was
> hoping to upgrade to Spring 1.2 RC2, but it doesn't look like this will
> work - unless the Acegi Team releases a new version that supports 1.2 RC2
> (hint, hint ;-). </matt>
>
> I've refactored the static PathMatcher into a PathMatcher interface and
> AntPathMatcher implementation class, after repeated questions in that
> respect. I must admit I haven't really considered that other *libraries*
> might access that code, just that users might.
>
> Hence, I've accepted the tradeoff of backwards-incompatibility for 1.2,
> because it's easy enough for users to migrate affected code - and the
> utilities in Spring's util package are considered somewhat for internal u=
se
> in the first place. But unfortunately, there's the issue of collaborating
> libraries...
>
> Anyway, I would like to keep the refactored PathMatcher, so I'd like to
> encourage you to release an Acegi update release (0.8.2?) at your earliest
> convenience, ideally alongside Spring 1.2 final (in about two weeks) or
> earlier. Users should have a fully working combo then again.
>
> Sorry for the inconveniences caused,
>
> Juergen
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: New Crystal Reports XI.
> Version 11 adds new functionality designed to reduce time involved in
> creating, integrating, and deploying reporting solutions. Free runtime
> info, new features, or free trial, at:
> http://www.businessobjects.com/devxi/728
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] OpenSessionInView and portlet support

[Juergen H. <ju...@in...>]

Well, if OpenSessionInViewFilter doesn't kick in for portlets, no other
filter will kick in with portlets either. Isn't there maybe some general
issue hiding there?

Of course we can provide an OpenSessionInViewInterceptor for portlets, but
I'm not sure whether that's actually a good fit there. The Portlet request
flow with separate handle and render callbacks makes this less compelling.

What we certainly can't do is let the existing OpenSessionInViewInterceptor
implement some PortletControllerInterceptor interface. That would force
every Servlet user to have the portlet.jar on the classpath.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Erwin Vervaet
Sent: Tuesday, April 19, 2005 9:26 PM
To: spr...@li...
Subject: [Springframework-developer] OpenSessionInView and portlet
support


Apparently the existing OSIV filter does not work with portlets:

http://forum.springframework.org/viewtopic.php?t=4907

I guess we should tackle this issue when doing the Portlet support for 1.3.
There is no PortletMVC category in JIRA so I'm not sure where to file it...
Any input from the Porlet people?

Erwin Vervaet
erw...@er...



-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring 1.2 RC2 and Acegi Security

[Juergen H. <ju...@in...>]

Everybody,

Please report any other libraries that have issues with the refactored
PathMatcher, or with any other changes in Spring 1.2 RC1/RC2. We should
catch all of those before the 1.2 final release.

If there are severe obstacles caused by this, we could also revert
PathMatcher back to a static utility class, as of 1.2 final. I would really
prefer to keep it as interface + implementation, though, which it should
have been from the start,

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Juergen Hoeller
Sent: Tuesday, April 19, 2005 9:11 PM
To: ben...@ac...
Cc: spr...@li...
Subject: [Springframework-developer] Spring 1.2 RC2 and Acegi Security


Hi Ben,

as Matt has noticed, there is a change in Spring 1.2 RC2 that breaks Acegi
Security:

<matt>
It's cool to see that the Spring Team has released 1.2 RC2, but there's a
change that causes Acegi Security (v0.8.1) to fail.

• refactored static PathMatcher class into PathMatcher interface and
AntPathMatcher implementation

This change seems to cause this issue with Acegi Security. Right now, I have
Spring 1.2 RC1 and Hibernate 3.0.1 bundled into AppFuse 1.8. I was hoping to
upgrade to Spring 1.2 RC2, but it doesn't look like this will work - unless
the Acegi Team releases a new version that supports 1.2 RC2 (hint, hint ;-).
</matt>

I've refactored the static PathMatcher into a PathMatcher interface and
AntPathMatcher implementation class, after repeated questions in that
respect. I must admit I haven't really considered that other *libraries*
might access that code, just that users might.

Hence, I've accepted the tradeoff of backwards-incompatibility for 1.2,
because it's easy enough for users to migrate affected code - and the
utilities in Spring's util package are considered somewhat for internal use
in the first place. But unfortunately, there's the issue of collaborating
libraries...

Anyway, I would like to keep the refactored PathMatcher, so I'd like to
encourage you to release an Acegi update release (0.8.2?) at your earliest
convenience, ideally alongside Spring 1.2 final (in about two weeks) or
earlier. Users should have a fully working combo then again.

Sorry for the inconveniences caused,

Juergen



-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] OpenSessionInView and portlet support

[Erwin V. <erw...@er...>]

Apparently the existing OSIV filter does not work with portlets:

http://forum.springframework.org/viewtopic.php?t=4907

I guess we should tackle this issue when doing the Portlet support for 1.3. 
There is no PortletMVC category in JIRA so I'm not sure where to file it...
Any input from the Porlet people?

Erwin Vervaet
erw...@er... 

[Springframework-developer] Spring 1.2 RC2 and Acegi Security

[Juergen H. <ju...@in...>]

Hi Ben,

as Matt has noticed, there is a change in Spring 1.2 RC2 that breaks Acegi
Security:

<matt>
It's cool to see that the Spring Team has released 1.2 RC2, but there's a
change that causes Acegi Security (v0.8.1) to fail.

• refactored static PathMatcher class into PathMatcher interface and
AntPathMatcher implementation

This change seems to cause this issue with Acegi Security. Right now, I have
Spring 1.2 RC1 and Hibernate 3.0.1 bundled into AppFuse 1.8. I was hoping to
upgrade to Spring 1.2 RC2, but it doesn't look like this will work - unless
the Acegi Team releases a new version that supports 1.2 RC2 (hint, hint ;-).
</matt>

I've refactored the static PathMatcher into a PathMatcher interface and
AntPathMatcher implementation class, after repeated questions in that
respect. I must admit I haven't really considered that other *libraries*
might access that code, just that users might.

Hence, I've accepted the tradeoff of backwards-incompatibility for 1.2,
because it's easy enough for users to migrate affected code - and the
utilities in Spring's util package are considered somewhat for internal use
in the first place. But unfortunately, there's the issue of collaborating
libraries...

Anyway, I would like to keep the refactored PathMatcher, so I'd like to
encourage you to release an Acegi update release (0.8.2?) at your earliest
convenience, ideally alongside Spring 1.2 final (in about two weeks) or
earlier. Users should have a fully working combo then again.

Sorry for the inconveniences caused,

Juergen

Re: [Springframework-developer] Commons Validator

[Rob H. <ro...@ca...>]

I'm not that familiar with Commons Validator myself and I was wondering 
how that worked. I will be adding in validator-rules.xml and making the 
appropriate changes so that it works with the Spring Modules FieldChecks 
class.

Rob

Matt Raible wrote:

>
> On Apr 19, 2005, at 9:48 AM, Rob Harrop wrote:
>
>>
>> Matt,
>>  
>> Spring Modules 0.1 is going out to tomorrow we reworked Commons  
>> Validator support. I would certainly appreciate your feedback on it  
>> when you get a chance to us it.
>
>
> I updated from CVS and tried it - incorporating the changes listed in  
> changelog.txt.  Here's what I had to change to migrate from the  
> previous version (which mainly required package-name changes).
>
> BeanValidator -> DefaultBeanValidator
> Remove init-method attribute from ValidatorFactory
> Change "resources" property on ValidatorFactory to  
> "validationConfigLocations"
>
> Everything seems to work great.  Are there any additional changes you  
> plan on making before the 0.1 release?
>
> One thing I noticed in Validator 1.1.3 is that much of the JavaScript  
> is generated from code inside the JAR, rather than a  
> validator-rules.xml file.  I'm guessing validator-rules.xml is still  
> required for Spring integration? Yep, answered my own question: 
> leaving  it out results in:
>
> java.lang.NullPointerException: Depends string "required" was not 
> found  in validator-rules.xml.
>     at  
> org.springmodules.commons.validator.taglib.JavascriptValidatorTag.doStar 
> tTag(JavascriptValidatorTag.java:334)
>
> Maybe this file should be included in the release somehow - or we  
> should figure out a way to override the JavaScript that's generated  
> from inside commons-validator.jar?  The guys on the validator list 
> are  pretty friendly, so I'm guessing they'd be willing to help out 
> with  this.
>
> Matt
>
>>  
>> Rob
>>  
>>
>> From: spr...@li...  
>> [mailto:spr...@li...] On  
>> Behalf Of Matt Raible
>> Sent: 19 April 2005 17:04
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] Where does webflow live?
>>  
>>
>> So what's the recommended strategy here? Do you guys recommend I 
>> drop  spring-sandbox.jar from AppFuse/Equinox and use the 
>> springmodules  version of Commons Validator support? My guess is "yes".
>>
>>  It would be nice if there was a release of the validator support on  
>> java.net?. Is it possible to publish a 1.0 version of the validator  
>> JAR?
>>
>>  Thanks,
>>
>>  Matt
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: New Crystal Reports XI.
> Version 11 adds new functionality designed to reduce time involved in
> creating, integrating, and deploying reporting solutions. Free runtime 
> info,
> new features, or free trial, at: http://www.businessobjects.com/devxi/728
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

[Springframework-developer] Commons Validator (was: Where does webflow live?)

[Matt R. <li...@ra...>]

On Apr 19, 2005, at 9:48 AM, Rob Harrop wrote:

>
> Matt,
> =A0
> Spring Modules 0.1 is going out to tomorrow we reworked Commons =20
> Validator support. I would certainly appreciate your feedback on it =20=

> when you get a chance to us it.

I updated from CVS and tried it - incorporating the changes listed in =20=

changelog.txt.  Here's what I had to change to migrate from the =20
previous version (which mainly required package-name changes).

BeanValidator -> DefaultBeanValidator
Remove init-method attribute from ValidatorFactory
Change "resources" property on ValidatorFactory to =20
"validationConfigLocations"

Everything seems to work great.  Are there any additional changes you =20=

plan on making before the 0.1 release?

One thing I noticed in Validator 1.1.3 is that much of the JavaScript =20=

is generated from code inside the JAR, rather than a =20
validator-rules.xml file.  I'm guessing validator-rules.xml is still =20
required for Spring integration? Yep, answered my own question: leaving =20=

it out results in:

java.lang.NullPointerException: Depends string "required" was not found =20=

in validator-rules.xml.
	at =20
org.springmodules.commons.validator.taglib.JavascriptValidatorTag.doStar=20=

tTag(JavascriptValidatorTag.java:334)

Maybe this file should be included in the release somehow - or we =20
should figure out a way to override the JavaScript that's generated =20
from inside commons-validator.jar?  The guys on the validator list are =20=

pretty friendly, so I'm guessing they'd be willing to help out with =20
this.

Matt

> =A0
> Rob
> =A0
>
> From: spr...@li... =20
> [mailto:spr...@li...] On =20
> Behalf Of Matt Raible
> Sent: 19 April 2005 17:04
> To: spr...@li...
> Subject: Re: [Springframework-developer] Where does webflow live?
> =A0
>
> So what's the recommended strategy here? Do you guys recommend I drop =20=

> spring-sandbox.jar from AppFuse/Equinox and use the springmodules =20
> version of Commons Validator support? My guess is "yes".
>
>  It would be nice if there was a release of the validator support on =20=

> java.net?. Is it possible to publish a 1.0 version of the validator =20=

> JAR?
>
>  Thanks,
>
>  Matt
>

RE: [Springframework-developer] Where does webflow live?

[Rob H. <rob...@in...>]

Matt,

 

Spring Modules 0.1 is going out to tomorrow we reworked Commons Validator
support. I would certainly appreciate your feedback on it when you get a
chance to us it.

 

Rob

 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Matt Raible
Sent: 19 April 2005 17:04
To: spr...@li...
Subject: Re: [Springframework-developer] Where does webflow live?

 

So what's the recommended strategy here? Do you guys recommend I drop
spring-sandbox.jar from AppFuse/Equinox and use the springmodules version of
Commons Validator support? My guess is "yes". 

It would be nice if there was a release of the validator support on
java.net?. Is it possible to publish a 1.0 version of the validator JAR?

Thanks,

Matt

On Apr 14, 2005, at 4:23 PM, Matt Raible wrote:

I checked and I have the latest stuff from CVS, but I did have last night's
and today's JARs in my deployed app. ;-) All seems to work fine now - nice
job!

Matt

On Apr 14, 2005, at 4:30 PM, Thomas Risberg wrote:

Matt,

Are you using the most recent version from CVS - I got the same error
yesterday - it was due to a refactoring misstake in the following line in
DefaultValidatorFactory:

private static final String ERRORS_KEY =
"org.springframework.validation.Errors";






the ERRORS_KEY was wrong so the null pointer exception was from a missing
error object. I did however fix it last night and my local tests run fine.

Thomas


On Apr 14, 2005, at 5:57 PM, Matt Raible wrote:

Client-side validation seems to work fine, but not server side. Here's the
error:

ERROR - ValidatorAction.executeValidationMethod(602) | Unhandled exception
thrown during validation: null
java.lang.NullPointerException
at
org.springmodules.commons.validator.Resources.rejectValue(Resources.java:66)
at
org.springmodules.commons.validator.FieldChecks.validateRequired(FieldChecks
.java:87)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)

Matt


On Apr 14, 2005, at 9:00 AM, Thomas Risberg wrote:

Matt,

I forgot the tld -- I have added it to the build. I changed the uri back to
http://www.springmodules.org/tags/commons-validator - same as before except
for the domain name.

Thanks for testing it :)

Thomas


On Apr 14, 2005, at 12:40 AM, Matt Raible wrote:

I tried it and the springmodules-validator-dev-20050413.jar seems to be
missing the taglib.tld in the META-INF directory. I built the project using
"ant alljars".

0 Wed Apr 13 22:12:46 MDT 2005 META-INF/
217 Wed Apr 13 22:12:44 MDT 2005 META-INF/MANIFEST.MF
0 Wed Apr 13 22:12:44 MDT 2005 org/
0 Wed Apr 13 22:12:44 MDT 2005 org/springmodules/
0 Wed Apr 13 22:12:44 MDT 2005 org/springmodules/commons/
0 Wed Apr 13 22:12:44 MDT 2005 org/springmodules/commons/validator/
0 Wed Apr 13 22:12:44 MDT 2005 org/springmodules/commons/validator/taglib/
2392 Wed Apr 13 22:12:44 MDT 2005
org/springmodules/commons/validator/BeanValidator.class
4596 Wed Apr 13 22:12:44 MDT 2005
org/springmodules/commons/validator/DefaultValidatorFactory.class
11261 Wed Apr 13 22:12:44 MDT 2005
org/springmodules/commons/validator/FieldChecks.class
3404 Wed Apr 13 22:12:44 MDT 2005
org/springmodules/commons/validator/NamedBeanValidator.class
4625 Wed Apr 13 22:12:44 MDT 2005
org/springmodules/commons/validator/Resources.class
2974 Wed Apr 13 22:12:44 MDT 2005
org/springmodules/commons/validator/ValidatorAdaptor.class
446 Wed Apr 13 22:12:44 MDT 2005
org/springmodules/commons/validator/ValidatorFactory.class
1305 Wed Apr 13 22:12:44 MDT 2005
org/springmodules/commons/validator/taglib/JavascriptValidatorTag$1.class
13579 Wed Apr 13 22:12:44 MDT 2005
org/springmodules/commons/validator/taglib/JavascriptValidatorTag.class

This results in the following error:

org.apache.jasper.JasperException: /index.jsp(1,1) The absolute uri:
http://www.springmodules.org/tags/spring-commons-validator cannot be
resolved in either web.xml or the jar files deployed with this application
at
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.
java:39)

BTW, is there any way to have a shorter URI - something like
http://www.springmodules.org/tags/validator?

Thanks,

Matt

On Apr 13, 2005, at 8:46 PM, Thomas Risberg wrote:

I have moved the Commons Validator support over to springmodules. I did not
make any changes other than the package names and copyright/license notices.
There are quite a few deprecated methods - I guess some of the code is for
an older version.

The new package name is org.springmodules.commons.validator
and the new uri for the taglib is
http://www.springmodules.org/tags/spring-commons-validator

Matt, since you seem to be the primary user of this support, could you check
the new code out and test it?

Thomas


On Apr 13, 2005, at 5:40 PM, Rob Harrop wrote:

Thomas,

If you are willing to work on it, I am happy for you to move it to Spring
Modules now. I don't see any harm in including what is there in a 0.1
release if you are happy with it.

Rob
On 13 Apr 2005, at 20:52, tho...@tr... wrote:

Rob,

I'm currently working on a project where I will use Commons Validator
outside of
a Web MVC environment. I still would like to be able to wire it up using
Spring
and I have been playing around with what's in the sandbox. I have already
changed the package names, so let me know when/if it is a good time to move
this to springmodules CVS.

I moved most of it to org.springmodules.validation.commons package except
for
the tag library which I put in
org.springmodules.web.servlet.tags.validation.commons. I guess it makes
sense
to keep the package structure in org.springmodules the same as
org.springframework so it's easier to move code between the projects.

Thomas


Quoting Rob Harrop <rob...@in...>:

Well, I'll spend some time going through the sandbox and see what I think is
a candidate for Spring Modules. I'll post the suggestions here and if
everyone is happy I'll do the move. We have about 6 active developers on SM
who are not core Spring devs, plus there is me so we may be able to breath
some live back into the stuff in the sandbox.

Rob

--
Rob Harrop
Interface21 - Spring Services from the Source
http://www.springframework.com

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Juergen Hoeller
Sent: 12 April 2005 22:17
To: spr...@li...
Subject: Re: [Springframework-developer] Where does webflow live?

Ah, our favorite topic once again ;-)

I'm not entirely sure whether Web Flow will get its own module; could be too
fine-granular. The binding framework quite certainly shouldn't, which would
already cause a problem with Web Flow's current status if we had modules.

To give some numbers: If we want to have the binding framework, JCA support,
Hibernate support, Web Flow, etc as separate modules (which would be
necessary to get your desired effect of not putting any early-access stuff
in the sandbox), we would end up with at least 35 modules (that's our
top-level packages plus some subpackages of relevant size). Frankly, I
consider that a horror scenario in terms of management and would strongly
vote against it.

I guess what I'm saying is that modules only *look* convincingly easy, but
won't be a general solution for the early access problem in practice. Keith,
please try to imagine this in detail and don't just consider it as solution
upfront. This is absolutely non-trivial when looking at the details.

Before we continue to spread the word on modules, I'd like to see concrete
suggestions for module separation, respecting the interdependencies outlined
in section 3 of our readme. I have already tried multiple times to nail down
some options, and have always failed to find a convincing separation.

The current jar files (12) might be a starting point, but I'm not sure that
they can serve as module granularity too... Some packages are joined
together there rather arbitrarily (from a source module perspective), for
example the ones in spring-support.jar, or the separation between
spring-orm.jar (which includes the entire ORM support except for Hibernate)
and spring-hibernate.jar. Those jar files cannot be mapped 1-to-1 to source
modules.

So in total, it's unclear to me how a concrete module separation could look
like (the more I look at it, the harder it seems). I doubt that we can
resolve this within the 1.3 timeframe, given that we have such an aggressive
schedule there, with just two months for multiple major new features.

Anyway, the real problem here is the sandbox, IMO. There's too much stuff in
there, both dead and somewhat alive. Noone should have to rely on
spring-sandbox.jar!! Everything that's of some use in there should move,
either to the core or to Spring Modules.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Keith Donald
Sent: Tuesday, April 12, 2005 9:24 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Where does webflow live?


Aye, this is exactly why we need a modular CVS structure and a smarter
build, which Colin is leading up in the post 1.2 timeframe.

Web flow is currently maintained in the sandbox, yes. This means it is also
included in spring-sandbox.jar when the 'sandboxjar' target is run.

Independent of that fact, the webflow.release target ships
spring-webflow.jar and spring-webflow-support.jar, pulling in _just_ the
required code from the sandbox needed to run spring webflow.

So, I guess you can say we've taken the stance that people aren't developing
apps with spring-sandbox.jar in their classpath. Hmm...

In any case, in the future spring-webflow will be in its own module with its
own distributable, along side other well-defined core modules, and the
sandbox will die the death it deserves (or be only used for true 'scratch'
stuff)

Keith




-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Matt Raible
Sent: Tuesday, April 12, 2005 3:04 PM
To: spr...@li...
Subject: [Springframework-developer] Where does webflow live?

I ran into some issues last night with spring-sandbox.jar from Spring
1.2 RC1 and Spring Web Flow PR2. The problem turned out to be that
many of the flow classes where already in my spring-sandbox.jar. Once
I deleted them from spring-sandbox.jar, everything worked fine. How do
I eliminate this duplication in the future? Is the web flow stuff in
spring-sandbox.jar? The main reason I'm using the sandbox JAR is for
Commons Validator.

Thanks,

Matt



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer






-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

-- 
Rob Harrop
Interface21 - Spring Services from the Source
http://www.springframework.com

Lead Developer - AOP & JMX, Spring Framework:
http://www.springframework.org

Author, "Pro Spring"
(February 2005, with Jan Machacek).
http://www.amazon.com/exec/obidos/ASIN/1590594614/

Author, "Pro Jakarta Velocity"
(August 2004).
http://www.amazon.com/exec/obidos/ASIN/159059410X/

Author, "Pro Jakarta Struts"
(March 2004, with John Carnell).
http://www.amazon.com/exec/obidos/ASIN/159059228X/


____________________________________________________
Interface21 Limited
Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY
Registered in England and Wales No. 5187766
____________________________________________________




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer






-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer






-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Where does webflow live?

[Matt R. <li...@ra...>]

So what's the recommended strategy here?  Do you guys recommend I drop  
spring-sandbox.jar from AppFuse/Equinox and use the springmodules  
version of Commons Validator support?  My guess is "yes".

It would be nice if there was a release of the validator support on  
java.net?. Is it possible to publish a 1.0 version of the validator  
JAR?

Thanks,

Matt

On Apr 14, 2005, at 4:23 PM, Matt Raible wrote:

> I checked and I have the latest stuff from CVS, but I did have last  
> night's and today's JARs in my deployed app. ;-)  All seems to work  
> fine now - nice job!
>
> Matt
>
> On Apr 14, 2005, at 4:30 PM, Thomas Risberg wrote:
>
>> Matt,
>>
>> Are you using the most recent version from CVS - I got the same error  
>> yesterday - it was due to a refactoring misstake in the following  
>> line in DefaultValidatorFactory:
>>
>> private static final String ERRORS_KEY =  
>> "org.springframework.validation.Errors";
>>
>>
>>
>> the ERRORS_KEY was wrong so the null pointer exception was from a  
>> missing error object.  I did however fix it last night and my local  
>> tests run fine.
>>
>> Thomas
>>
>>
>> On Apr 14, 2005, at 5:57 PM, Matt Raible wrote:
>>
>>> Client-side validation seems to work fine, but not server side.   
>>> Here's the error:
>>>
>>> ERROR - ValidatorAction.executeValidationMethod(602) | Unhandled  
>>> exception thrown during validation: null
>>> java.lang.NullPointerException
>>>         at  
>>> org.springmodules.commons.validator.Resources.rejectValue(Resources.j 
>>> ava:66)
>>>         at  
>>> org.springmodules.commons.validator.FieldChecks.validateRequired(Fiel 
>>> dChecks.java:87)
>>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native  
>>> Method)
>>>         at  
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. 
>>> java:39)
>>>
>>> Matt
>>>
>>>
>>> On Apr 14, 2005, at 9:00 AM, Thomas Risberg wrote:
>>>
>>>> Matt,
>>>>
>>>> I forgot the tld -- I have added it to the build.  I changed the  
>>>> uri back to http://www.springmodules.org/tags/commons-validator -  
>>>> same as before except for the domain name.
>>>>
>>>> Thanks for testing it :)
>>>>
>>>> Thomas
>>>>
>>>>
>>>> On Apr 14, 2005, at 12:40 AM, Matt Raible wrote:
>>>>
>>>>> I tried it and the springmodules-validator-dev-20050413.jar seems  
>>>>> to be missing the taglib.tld in the META-INF directory. I built  
>>>>> the project using "ant alljars".
>>>>>
>>>>>      0 Wed Apr 13 22:12:46 MDT 2005 META-INF/
>>>>>    217 Wed Apr 13 22:12:44 MDT 2005 META-INF/MANIFEST.MF
>>>>>      0 Wed Apr 13 22:12:44 MDT 2005 org/
>>>>>      0 Wed Apr 13 22:12:44 MDT 2005 org/springmodules/
>>>>>      0 Wed Apr 13 22:12:44 MDT 2005 org/springmodules/commons/
>>>>>      0 Wed Apr 13 22:12:44 MDT 2005  
>>>>> org/springmodules/commons/validator/
>>>>>      0 Wed Apr 13 22:12:44 MDT 2005  
>>>>> org/springmodules/commons/validator/taglib/
>>>>>   2392 Wed Apr 13 22:12:44 MDT 2005  
>>>>> org/springmodules/commons/validator/BeanValidator.class
>>>>>   4596 Wed Apr 13 22:12:44 MDT 2005  
>>>>> org/springmodules/commons/validator/DefaultValidatorFactory.class
>>>>>  11261 Wed Apr 13 22:12:44 MDT 2005  
>>>>> org/springmodules/commons/validator/FieldChecks.class
>>>>>   3404 Wed Apr 13 22:12:44 MDT 2005  
>>>>> org/springmodules/commons/validator/NamedBeanValidator.class
>>>>>   4625 Wed Apr 13 22:12:44 MDT 2005  
>>>>> org/springmodules/commons/validator/Resources.class
>>>>>   2974 Wed Apr 13 22:12:44 MDT 2005  
>>>>> org/springmodules/commons/validator/ValidatorAdaptor.class
>>>>>    446 Wed Apr 13 22:12:44 MDT 2005  
>>>>> org/springmodules/commons/validator/ValidatorFactory.class
>>>>>   1305 Wed Apr 13 22:12:44 MDT 2005  
>>>>> org/springmodules/commons/validator/taglib/ 
>>>>> JavascriptValidatorTag$1.class
>>>>>  13579 Wed Apr 13 22:12:44 MDT 2005  
>>>>> org/springmodules/commons/validator/taglib/ 
>>>>> JavascriptValidatorTag.class
>>>>>
>>>>> This results in the following error:
>>>>>
>>>>> org.apache.jasper.JasperException: /index.jsp(1,1) The absolute  
>>>>> uri: http://www.springmodules.org/tags/spring-commons-validator  
>>>>> cannot be resolved in either web.xml or the jar files deployed  
>>>>> with this application
>>>>> 	at  
>>>>> org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErro 
>>>>> rHandler.java:39)
>>>>>
>>>>> BTW, is there any way to have a shorter URI - something like  
>>>>> http://www.springmodules.org/tags/validator?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Matt
>>>>>
>>>>> On Apr 13, 2005, at 8:46 PM, Thomas Risberg wrote:
>>>>>
>>>>>> I have moved the Commons Validator support over to springmodules.  
>>>>>>  I did not make any changes other than the package names and   
>>>>>> copyright/license notices.  There are quite a few deprecated  
>>>>>> methods - I guess some of the code is for an older version.
>>>>>>
>>>>>> The new package name is org.springmodules.commons.validator
>>>>>> and the new uri for the taglib is    
>>>>>> http://www.springmodules.org/tags/spring-commons-validator
>>>>>>
>>>>>> Matt, since you seem to be the primary user of this support,  
>>>>>> could you check the new code out and test it?
>>>>>>
>>>>>> Thomas
>>>>>>
>>>>>>
>>>>>> On Apr 13, 2005, at 5:40 PM, Rob Harrop wrote:
>>>>>>
>>>>>>> Thomas,
>>>>>>>
>>>>>>> If you are willing to work on it, I am happy for you to move it  
>>>>>>> to Spring Modules now. I don't see any harm in including what is  
>>>>>>> there in a 0.1 release if you are happy with it.
>>>>>>>
>>>>>>> Rob
>>>>>>> On 13 Apr 2005, at 20:52, tho...@tr... wrote:
>>>>>>>
>>>>>>>> Rob,
>>>>>>>>
>>>>>>>> I'm currently working on a project where I will use Commons  
>>>>>>>> Validator outside of
>>>>>>>> a Web MVC environment.  I still would like to be able to wire  
>>>>>>>> it up using Spring
>>>>>>>> and I have been playing around with what's in the sandbox.  I  
>>>>>>>> have already
>>>>>>>> changed the package names, so let me know when/if it is a good  
>>>>>>>> time to move
>>>>>>>> this to springmodules CVS.
>>>>>>>>
>>>>>>>> I moved most of it to org.springmodules.validation.commons  
>>>>>>>> package except for
>>>>>>>> the tag library which I put in
>>>>>>>> org.springmodules.web.servlet.tags.validation.commons.  I guess  
>>>>>>>> it makes sense
>>>>>>>> to keep the package structure in org.springmodules the same as
>>>>>>>> org.springframework so it's easier to move code between the  
>>>>>>>> projects.
>>>>>>>>
>>>>>>>> Thomas
>>>>>>>>
>>>>>>>>
>>>>>>>> Quoting Rob Harrop <rob...@in...>:
>>>>>>>>
>>>>>>>>> Well, I'll spend some time going through the sandbox and see  
>>>>>>>>> what I think is
>>>>>>>>> a candidate for Spring Modules. I'll post the suggestions here  
>>>>>>>>> and if
>>>>>>>>> everyone is happy I'll do the move. We have about 6 active  
>>>>>>>>> developers on SM
>>>>>>>>> who are not core Spring devs, plus there is me so we may be  
>>>>>>>>> able to breath
>>>>>>>>> some live back into the stuff in the sandbox.
>>>>>>>>>
>>>>>>>>> Rob
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Rob Harrop
>>>>>>>>> Interface21 - Spring Services from the Source
>>>>>>>>> http://www.springframework.com
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: spr...@li...
>>>>>>>>> [mailto:spr...@li...]  
>>>>>>>>> On Behalf Of
>>>>>>>>> Juergen Hoeller
>>>>>>>>> Sent: 12 April 2005 22:17
>>>>>>>>> To: spr...@li...
>>>>>>>>> Subject: Re: [Springframework-developer] Where does webflow  
>>>>>>>>> live?
>>>>>>>>>
>>>>>>>>> Ah, our favorite topic once again ;-)
>>>>>>>>>
>>>>>>>>> I'm not entirely sure whether Web Flow will get its own  
>>>>>>>>> module; could be too
>>>>>>>>> fine-granular. The binding framework quite certainly  
>>>>>>>>> shouldn't, which would
>>>>>>>>> already cause a problem with Web Flow's current status if we  
>>>>>>>>> had modules.
>>>>>>>>>
>>>>>>>>> To give some numbers: If we want to have the binding  
>>>>>>>>> framework, JCA support,
>>>>>>>>> Hibernate support, Web Flow, etc as separate modules (which  
>>>>>>>>> would be
>>>>>>>>> necessary to get your desired effect of not putting any  
>>>>>>>>> early-access stuff
>>>>>>>>> in the sandbox), we would end up with at least 35 modules  
>>>>>>>>> (that's our
>>>>>>>>> top-level packages plus some subpackages of relevant size).  
>>>>>>>>> Frankly, I
>>>>>>>>> consider that a horror scenario in terms of management and  
>>>>>>>>> would strongly
>>>>>>>>> vote against it.
>>>>>>>>>
>>>>>>>>> I guess what I'm saying is that modules only *look*  
>>>>>>>>> convincingly easy, but
>>>>>>>>> won't be a general solution for the early access problem in  
>>>>>>>>> practice. Keith,
>>>>>>>>> please try to imagine this in detail and don't just consider  
>>>>>>>>> it as solution
>>>>>>>>> upfront. This is absolutely non-trivial when looking at the  
>>>>>>>>> details.
>>>>>>>>>
>>>>>>>>> Before we continue to spread the word on modules, I'd like to  
>>>>>>>>> see concrete
>>>>>>>>> suggestions for module separation, respecting the  
>>>>>>>>> interdependencies outlined
>>>>>>>>> in section 3 of our readme. I have already tried multiple  
>>>>>>>>> times to nail down
>>>>>>>>> some options, and have always failed to find a convincing  
>>>>>>>>> separation.
>>>>>>>>>
>>>>>>>>> The current jar files (12) might be a starting point, but I'm  
>>>>>>>>> not sure that
>>>>>>>>> they can serve as module granularity too... Some packages are  
>>>>>>>>> joined
>>>>>>>>> together there rather arbitrarily (from a source module  
>>>>>>>>> perspective), for
>>>>>>>>> example the ones in spring-support.jar, or the separation  
>>>>>>>>> between
>>>>>>>>> spring-orm.jar (which includes the entire ORM support except  
>>>>>>>>> for Hibernate)
>>>>>>>>> and spring-hibernate.jar. Those jar files cannot be mapped  
>>>>>>>>> 1-to-1 to source
>>>>>>>>> modules.
>>>>>>>>>
>>>>>>>>> So in total, it's unclear to me how a concrete module  
>>>>>>>>> separation could look
>>>>>>>>> like (the more I look at it, the harder it seems). I doubt  
>>>>>>>>> that we can
>>>>>>>>> resolve this within the 1.3 timeframe, given that we have such  
>>>>>>>>> an aggressive
>>>>>>>>> schedule there, with just two months for multiple major new  
>>>>>>>>> features.
>>>>>>>>>
>>>>>>>>> Anyway, the real problem here is the sandbox, IMO. There's too  
>>>>>>>>> much stuff in
>>>>>>>>> there, both dead and somewhat alive. Noone should have to rely  
>>>>>>>>> on
>>>>>>>>> spring-sandbox.jar!! Everything that's of some use in there  
>>>>>>>>> should move,
>>>>>>>>> either to the core or to Spring Modules.
>>>>>>>>>
>>>>>>>>> Juergen
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: spr...@li...
>>>>>>>>> [mailto:springframework-developer- 
>>>>>>>>> ad...@li...]On Behalf
>>>>>>>>> Of Keith Donald
>>>>>>>>> Sent: Tuesday, April 12, 2005 9:24 PM
>>>>>>>>> To: spr...@li...
>>>>>>>>> Subject: RE: [Springframework-developer] Where does webflow  
>>>>>>>>> live?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Aye, this is exactly why we need a modular CVS structure and a  
>>>>>>>>> smarter
>>>>>>>>> build, which Colin is leading up in the post 1.2 timeframe.
>>>>>>>>>
>>>>>>>>> Web flow is currently maintained in the sandbox, yes.  This  
>>>>>>>>> means it is also
>>>>>>>>> included in spring-sandbox.jar when the 'sandboxjar' target is  
>>>>>>>>> run.
>>>>>>>>>
>>>>>>>>> Independent of that fact, the webflow.release target ships
>>>>>>>>> spring-webflow.jar and spring-webflow-support.jar, pulling in  
>>>>>>>>> _just_ the
>>>>>>>>> required code from the sandbox needed to run spring webflow.
>>>>>>>>>
>>>>>>>>> So, I guess you can say we've taken the stance that people  
>>>>>>>>> aren't developing
>>>>>>>>> apps with spring-sandbox.jar in their classpath.  Hmm...
>>>>>>>>>
>>>>>>>>> In any case, in the future spring-webflow will be in its own  
>>>>>>>>> module with its
>>>>>>>>> own distributable, along side other well-defined core modules,  
>>>>>>>>> and the
>>>>>>>>> sandbox will die the death it deserves (or be only used for  
>>>>>>>>> true 'scratch'
>>>>>>>>> stuff)
>>>>>>>>>
>>>>>>>>> Keith
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: spr...@li...
>>>>>>>>> [mailto:spr...@li...]  
>>>>>>>>> On Behalf Of
>>>>>>>>> Matt Raible
>>>>>>>>> Sent: Tuesday, April 12, 2005 3:04 PM
>>>>>>>>> To: spr...@li...
>>>>>>>>> Subject: [Springframework-developer] Where does webflow live?
>>>>>>>>>
>>>>>>>>> I ran into some issues last night with spring-sandbox.jar from  
>>>>>>>>> Spring
>>>>>>>>> 1.2 RC1 and Spring Web Flow PR2.  The problem turned out to be  
>>>>>>>>> that
>>>>>>>>> many of the flow classes where already in my  
>>>>>>>>> spring-sandbox.jar.  Once
>>>>>>>>> I deleted them from spring-sandbox.jar, everything worked  
>>>>>>>>> fine.  How do
>>>>>>>>> I eliminate this duplication in the future?  Is the web flow  
>>>>>>>>> stuff in
>>>>>>>>> spring-sandbox.jar?  The main reason I'm using the sandbox JAR  
>>>>>>>>> is for
>>>>>>>>> Commons Validator.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Matt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -------------------------------------------------------
>>>>>>>>> SF email is sponsored by - The IT Product Guide
>>>>>>>>> Read honest & candid reviews on hundreds of IT Products from  
>>>>>>>>> real users.
>>>>>>>>> Discover which products truly live up to the hype. Start  
>>>>>>>>> reading now.
>>>>>>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>>>>>> _______________________________________________
>>>>>>>>> Springframework-developer mailing list
>>>>>>>>> Spr...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>>>>>>>>> developer
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -------------------------------------------------------
>>>>>>>>> SF email is sponsored by - The IT Product Guide
>>>>>>>>> Read honest & candid reviews on hundreds of IT Products from  
>>>>>>>>> real users.
>>>>>>>>> Discover which products truly live up to the hype. Start  
>>>>>>>>> reading now.
>>>>>>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>>>>>> _______________________________________________
>>>>>>>>> Springframework-developer mailing list
>>>>>>>>> Spr...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>>>>>>>>> developer
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -------------------------------------------------------
>>>>>>>>> SF email is sponsored by - The IT Product Guide
>>>>>>>>> Read honest & candid reviews on hundreds of IT Products from  
>>>>>>>>> real users.
>>>>>>>>> Discover which products truly live up to the hype. Start  
>>>>>>>>> reading now.
>>>>>>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>>>>>> _______________________________________________
>>>>>>>>> Springframework-developer mailing list
>>>>>>>>> Spr...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>>>>>>>>> developer
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -------------------------------------------------------
>>>>>>>>> SF email is sponsored by - The IT Product Guide
>>>>>>>>> Read honest & candid reviews on hundreds of IT Products from  
>>>>>>>>> real users.
>>>>>>>>> Discover which products truly live up to the hype. Start  
>>>>>>>>> reading now.
>>>>>>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>>>>>> _______________________________________________
>>>>>>>>> Springframework-developer mailing list
>>>>>>>>> Spr...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>>>>>>>>> developer
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -------------------------------------------------------
>>>>>>>> SF email is sponsored by - The IT Product Guide
>>>>>>>> Read honest & candid reviews on hundreds of IT Products from  
>>>>>>>> real users.
>>>>>>>> Discover which products truly live up to the hype. Start  
>>>>>>>> reading now.
>>>>>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>>>>> _______________________________________________
>>>>>>>> Springframework-developer mailing list
>>>>>>>> Spr...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>>>>>>>> developer
>>>>>>>>
>>>>>>> -- 
>>>>>>> Rob Harrop
>>>>>>> Interface21 - Spring Services from the Source
>>>>>>> http://www.springframework.com
>>>>>>>
>>>>>>> Lead Developer - AOP & JMX, Spring Framework:
>>>>>>> http://www.springframework.org
>>>>>>>
>>>>>>> Author, "Pro Spring"
>>>>>>> (February 2005, with Jan Machacek).
>>>>>>> http://www.amazon.com/exec/obidos/ASIN/1590594614/
>>>>>>>
>>>>>>> Author, "Pro Jakarta Velocity"
>>>>>>> (August 2004).
>>>>>>> http://www.amazon.com/exec/obidos/ASIN/159059410X/
>>>>>>>
>>>>>>> Author, "Pro Jakarta Struts"
>>>>>>> (March 2004, with John Carnell).
>>>>>>> http://www.amazon.com/exec/obidos/ASIN/159059228X/
>>>>>>>
>>>>>>>
>>>>>>> ____________________________________________________
>>>>>>> Interface21 Limited
>>>>>>> Registered Office Summit House, 2-2a Highfield Road, Dartford,  
>>>>>>> Kent DA1 2JY
>>>>>>> Registered in England and Wales No. 5187766
>>>>>>> ____________________________________________________
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -------------------------------------------------------
>>>>>>> SF email is sponsored by - The IT Product Guide
>>>>>>> Read honest & candid reviews on hundreds of IT Products from  
>>>>>>> real users.
>>>>>>> Discover which products truly live up to the hype. Start reading  
>>>>>>> now.
>>>>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>>>> _______________________________________________
>>>>>>> Springframework-developer mailing list
>>>>>>> Spr...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>>>>>>> developer
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -------------------------------------------------------
>>>>>> SF email is sponsored by - The IT Product Guide
>>>>>> Read honest & candid reviews on hundreds of IT Products from real  
>>>>>> users.
>>>>>> Discover which products truly live up to the hype. Start reading  
>>>>>> now.
>>>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>>> _______________________________________________
>>>>>> Springframework-developer mailing list
>>>>>> Spr...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>>>>>> developer
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> SF email is sponsored by - The IT Product Guide
>>>>> Read honest & candid reviews on hundreds of IT Products from real  
>>>>> users.
>>>>> Discover which products truly live up to the hype. Start reading  
>>>>> now.
>>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>> _______________________________________________
>>>>> Springframework-developer mailing list
>>>>> Spr...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>>>>> developer
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> SF email is sponsored by - The IT Product Guide
>>>> Read honest & candid reviews on hundreds of IT Products from real  
>>>> users.
>>>> Discover which products truly live up to the hype. Start reading  
>>>> now.
>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>> _______________________________________________
>>>> Springframework-developer mailing list
>>>> Spr...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>>>> developer
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF email is sponsored by - The IT Product Guide
>>> Read honest & candid reviews on hundreds of IT Products from real  
>>> users.
>>> Discover which products truly live up to the hype. Start reading now.
>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>>> developer
>>>
>>>

[Springframework-developer] Preparing for 1.2 final

[Juergen H. <ju...@in...>]

Dear Spring developers,

Please have a look at the current JIRA issues for 1.2 final. If you find
anything in there that's assigned to you but unlikely to be finished within
the next two weeks, please move the issue it to a later milestone (or close
it if you don't intend to address it at all).

A lot of those issues are doc issues, actually. I have been moving them
along for a while now, some of them since January. I would particularly
appreciate any work on those doc issues, to finally get them done for 1.2
final. Else, feel free to move them to 1.2.1 or 1.3 RC1, according to your
plans.

Cheers,

Juergen

Re: [Springframework-developer] Spring Framework 1.2 RC2 released

[Thomas R. <tho...@tr...>]

JavaDocs are done - are we ever going to automate this :)

Thomas


On Apr 18, 2005, at 9:39 PM, Colin Sampaleanu wrote:

> I updated the docs, and posted notices on the forums and 
> springframework.com. So the JavaDocs are all that is left.
>
> Colin
>
> Thomas Risberg wrote:
>
>> I updated the home page and the news page - will do the api docs as 
>> soon as my download completes.
>>
>> Thomas
>>
>>
>> On Apr 18, 2005, at 5:21 PM, Juergen Hoeller wrote:
>>
>>> I'm pleased to announce that Spring 1.2 RC2 has just been released.
>>>
>>> This release introduces one major new feature:
>>>
>>> * support for JCA's Common Client Interface (CCI), including support 
>>> for CCI
>>> local transactions
>>>
>>> Furthermore, there are various minor enhancements, for example:
>>>
>>> * deprecated ListableBeanFactory's "getBeanDefinitionNames(type)", 
>>> in favor
>>> of "getBeanNamesForType"
>>> * added "value"/"value-ref" shortcut attributes to XML "entry" tag 
>>> for maps
>>> * added "alias" root element for XML bean definition files, for 
>>> aliases for
>>> beans in other files
>>>
>>> * JdbcAccessor lazily initializes the SQLExceptionTranslator by 
>>> default now
>>> * added further configuration options to LocalSessionFactoryBean for
>>> Hibernate3
>>> * added "defaultDestinationName" property to JmsTemplate, for a 
>>> dynamic
>>> default destination
>>>
>>> * refined Resource support for compatibility with JDK 1.3's classic 
>>> VM and
>>> with JRockit's jar paths
>>> * refactored static PathMatcher class into PathMatcher interface and
>>> AntPathMatcher implementation
>>> * added ConfigurableMimeFileTypeMap, with extensive MIME type 
>>> mappings
>>> out-of-the-box
>>>
>>> * added "context.i18n" package, with LocaleContext abstraction and 
>>> global
>>> LocaleContextHolder
>>> * DispatcherServlet exposes the current LocaleResolver through the 
>>> global
>>> LocaleContextHolder
>>> * added RemoteInvocationTraceInterceptor, logging remote calls and
>>> exceptions on the server
>>>
>>> * updated JasperReports support for JR 0.6.6, using 
>>> JRDefaultCompiler as
>>> default report compiler
>>> * reworked AbstractJasperReportsView to work on JasperPrint instance 
>>> rather
>>> than JasperReport instance
>>> * added support for reports with embedded SQL statements to
>>> AbstractJasperReportsView
>>>
>>> For a detailed list of enhancements and bug fixes, see the changelog.
>>>
>>> This release candidate is considered stable and recommended for 
>>> development
>>> use. We expect Spring 1.2 final to be released in about two weeks.
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: New Crystal Reports XI.
>> Version 11 adds new functionality designed to reduce time involved in
>> creating, integrating, and deploying reporting solutions. Free 
>> runtime info,
>> new features, or free trial, at: 
>> http://www.businessobjects.com/devxi/728
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -- 
> Colin Sampaleanu
> Interface21 Principal Consultant
> Spring Training, Consulting and Support - "From the Source"
> http://www.springframework.com
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: New Crystal Reports XI.
> Version 11 adds new functionality designed to reduce time involved in
> creating, integrating, and deploying reporting solutions. Free runtime 
> info,
> new features, or free trial, at: 
> http://www.businessobjects.com/devxi/728
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

Re: [Springframework-developer] Spring Framework 1.2 RC2 released

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

I updated the docs, and posted notices on the forums and 
springframework.com. So the JavaDocs are all that is left.

Colin

Thomas Risberg wrote:

> I updated the home page and the news page - will do the api docs as 
> soon as my download completes.
>
> Thomas
>
>
> On Apr 18, 2005, at 5:21 PM, Juergen Hoeller wrote:
>
>> I'm pleased to announce that Spring 1.2 RC2 has just been released.
>>
>> This release introduces one major new feature:
>>
>> * support for JCA's Common Client Interface (CCI), including support 
>> for CCI
>> local transactions
>>
>> Furthermore, there are various minor enhancements, for example:
>>
>> * deprecated ListableBeanFactory's "getBeanDefinitionNames(type)", in 
>> favor
>> of "getBeanNamesForType"
>> * added "value"/"value-ref" shortcut attributes to XML "entry" tag 
>> for maps
>> * added "alias" root element for XML bean definition files, for 
>> aliases for
>> beans in other files
>>
>> * JdbcAccessor lazily initializes the SQLExceptionTranslator by 
>> default now
>> * added further configuration options to LocalSessionFactoryBean for
>> Hibernate3
>> * added "defaultDestinationName" property to JmsTemplate, for a dynamic
>> default destination
>>
>> * refined Resource support for compatibility with JDK 1.3's classic 
>> VM and
>> with JRockit's jar paths
>> * refactored static PathMatcher class into PathMatcher interface and
>> AntPathMatcher implementation
>> * added ConfigurableMimeFileTypeMap, with extensive MIME type mappings
>> out-of-the-box
>>
>> * added "context.i18n" package, with LocaleContext abstraction and 
>> global
>> LocaleContextHolder
>> * DispatcherServlet exposes the current LocaleResolver through the 
>> global
>> LocaleContextHolder
>> * added RemoteInvocationTraceInterceptor, logging remote calls and
>> exceptions on the server
>>
>> * updated JasperReports support for JR 0.6.6, using JRDefaultCompiler as
>> default report compiler
>> * reworked AbstractJasperReportsView to work on JasperPrint instance 
>> rather
>> than JasperReport instance
>> * added support for reports with embedded SQL statements to
>> AbstractJasperReportsView
>>
>> For a detailed list of enhancements and bug fixes, see the changelog.
>>
>> This release candidate is considered stable and recommended for 
>> development
>> use. We expect Spring 1.2 final to be released in about two weeks.
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: New Crystal Reports XI.
> Version 11 adds new functionality designed to reduce time involved in
> creating, integrating, and deploying reporting solutions. Free runtime 
> info,
> new features, or free trial, at: http://www.businessobjects.com/devxi/728
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

Re: [Springframework-developer] Spring Framework 1.2 RC2 released

[Thomas R. <tho...@tr...>]

I updated the home page and the news page - will do the api docs as 
soon as my download completes.

Thomas


On Apr 18, 2005, at 5:21 PM, Juergen Hoeller wrote:

> I'm pleased to announce that Spring 1.2 RC2 has just been released.
>
> This release introduces one major new feature:
>
> * support for JCA's Common Client Interface (CCI), including support 
> for CCI
> local transactions
>
> Furthermore, there are various minor enhancements, for example:
>
> * deprecated ListableBeanFactory's "getBeanDefinitionNames(type)", in 
> favor
> of "getBeanNamesForType"
> * added "value"/"value-ref" shortcut attributes to XML "entry" tag for 
> maps
> * added "alias" root element for XML bean definition files, for 
> aliases for
> beans in other files
>
> * JdbcAccessor lazily initializes the SQLExceptionTranslator by 
> default now
> * added further configuration options to LocalSessionFactoryBean for
> Hibernate3
> * added "defaultDestinationName" property to JmsTemplate, for a dynamic
> default destination
>
> * refined Resource support for compatibility with JDK 1.3's classic VM 
> and
> with JRockit's jar paths
> * refactored static PathMatcher class into PathMatcher interface and
> AntPathMatcher implementation
> * added ConfigurableMimeFileTypeMap, with extensive MIME type mappings
> out-of-the-box
>
> * added "context.i18n" package, with LocaleContext abstraction and 
> global
> LocaleContextHolder
> * DispatcherServlet exposes the current LocaleResolver through the 
> global
> LocaleContextHolder
> * added RemoteInvocationTraceInterceptor, logging remote calls and
> exceptions on the server
>
> * updated JasperReports support for JR 0.6.6, using JRDefaultCompiler 
> as
> default report compiler
> * reworked AbstractJasperReportsView to work on JasperPrint instance 
> rather
> than JasperReport instance
> * added support for reports with embedded SQL statements to
> AbstractJasperReportsView
>
> For a detailed list of enhancements and bug fixes, see the changelog.
>
> This release candidate is considered stable and recommended for 
> development
> use. We expect Spring 1.2 final to be released in about two weeks.

[Springframework-developer] Spring Framework 1.2 RC2 released

[Juergen H. <ju...@in...>]

Dear Spring community,

I'm pleased to announce that Spring 1.2 RC2 has just been released.

This release introduces one major new feature:

* support for JCA's Common Client Interface (CCI), including support for CCI
local transactions

Furthermore, there are various minor enhancements, for example:

* deprecated ListableBeanFactory's "getBeanDefinitionNames(type)", in favor
of "getBeanNamesForType"
* added "value"/"value-ref" shortcut attributes to XML "entry" tag for maps
* added "alias" root element for XML bean definition files, for aliases for
beans in other files

* JdbcAccessor lazily initializes the SQLExceptionTranslator by default now
* added further configuration options to LocalSessionFactoryBean for
Hibernate3
* added "defaultDestinationName" property to JmsTemplate, for a dynamic
default destination

* refined Resource support for compatibility with JDK 1.3's classic VM and
with JRockit's jar paths
* refactored static PathMatcher class into PathMatcher interface and
AntPathMatcher implementation
* added ConfigurableMimeFileTypeMap, with extensive MIME type mappings
out-of-the-box

* added "context.i18n" package, with LocaleContext abstraction and global
LocaleContextHolder
* DispatcherServlet exposes the current LocaleResolver through the global
LocaleContextHolder
* added RemoteInvocationTraceInterceptor, logging remote calls and
exceptions on the server

* updated JasperReports support for JR 0.6.6, using JRDefaultCompiler as
default report compiler
* reworked AbstractJasperReportsView to work on JasperPrint instance rather
than JasperReport instance
* added support for reports with embedded SQL statements to
AbstractJasperReportsView

For a detailed list of enhancements and bug fixes, see the changelog.

This release candidate is considered stable and recommended for development
use. We expect Spring 1.2 final to be released in about two weeks.

Cheers,

Juergen

-----
Juergen Hoeller
Interface21 - Spring Services from the Source
http://www.springframework.com

RE: [Springframework-developer] MVC DispatcherSevlet vs HandlerServlet

[Alef A. <al...@jt...>]

>>=20
You do have a point there regarding MVC vs servlet support separation.
However, that would only work with a restructing of the package
hierarchy there, because the current "web.servlet" package is
essentially the direct basis for the controllers and views of the MVC
framework. If we wanted to separate those into different modules, we'd
get a problem, because we'd need to separate classes in the same
subpackage tree there.
=20
The current line drawn between spring-web.jar and spring-webmvc.jar is
that the latter includes "web.servlet" plus subpackages and the former
includes everything else. That works pretty well in general, because
spring-web.jar is all you need to make a Spring application context work
with Struts, JSF, Tapestry, any third-party MVC framework.
=20
Of course, once you want to export HTTP-based remote services, you do
need spring-webmvc.jar even when working with a third-party web MVC
framework. I consider that acceptable, though: spring-webmvc.jar simply
includes a generic dispatcher necessary for HTTP-based remoting, which
will coexist nicely with any third-party MVC framework.=20
>>
=20
Well, that's the point :). I personally don't consider including the
webmvc.jar to be a real issue but some people out there (and Jason isn't
the only one :) do! And it results in people creating custom code, which
I don't like :). Let's leave it like it is for now.

RE: [Springframework-developer] springmodules build.3 Build Successful

[Alef A. <al...@jt...>]

I'm trying to move the springmodules build notification to dev.java.net
but I haven't succeeded so far :). Sorry for the inconvenience.

Alef
=20

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of al...@in...
Sent: Monday, April 18, 2005 2:35 PM
To: spr...@li...
Subject: [Springframework-developer] springmodules build.3 Build
Successful

View results here ->
http://opensource.jteam.nl/build/buildresults/springmodules?log=3Dlog2005=
0
418143423Lbuild.3


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid
reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] springmodules build.3 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/springmodules?log=log20050418143423Lbuild.3