springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Creating documentation from Spring beans definition files (e.g. like HiveMind's HiveDoc)

[Torsten J. <tju...@ya...>]

Daniel,

sounds good. Is it possible to share this stylesheet?

Thanx.
Torsten

--- Daniel Potter <po...@ci...> wrote:
> I know it's not quite what you had in mind with this
> question, but we've
> used Graphviz
> (www.research.att.com/sw/tools/graphviz/) to
> generate dependency graphs based on Spring
> configuration files.  The
> basic process involves using an XSL stylesheet to
> transform the Spring
> XML config files into the .dot syntax used by
> Graphviz, then running
> Graphviz on the .dot files to generate png, gif,
> postscript, etc.
> dependency graphs.  Of course, this wouldn't work
> for autowired
> configurations, but it generates interesting and
> useful graphs for
> explicit configurations.
> 
> Daniel
> 
> On Tue, Apr 06, 2004 at 01:02:39AM -0700, Torsten
> Juergeleit wrote:
> > Is anyone already working on a way to create
> > documentation from Spring beans definition files?
> > 
> > Howard's HiveMind / HiveDoc
> > (http://jakarta.apache.org/hivemind/hivedoc.html)
> uses
> > XSL stylesheets to transform the HiveMind config
> files
> > into a set of HTML files. Sample output:
> >
>
http://jakarta.apache.org/hivemind/hivedocs/index.html
> > 
> > Does it make sense to create something similar for
> > Spring?
> > 
> > Torsten
> > 
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Small Business $15K Web Design Giveaway 
> > http://promotions.yahoo.com/design_giveaway/
> > 
> > 
> >
>
-------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux
> Tutorials
> > Free Linux tutorial presented by Daniel Robbins,
> President and CEO of
> > GenToo technologies. Learn everything from
> fundamentals to system
> >
>
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux
> Tutorials
> Free Linux tutorial presented by Daniel Robbins,
> President and CEO of
> GenToo technologies. Learn everything from
> fundamentals to system
>
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer


__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

Re: [Springframework-developer] Keep Spring Focused WAS: commons-validator adapter

[Peter d. H. <pe...@de...>]

The Spring core supports JDBC, iBatis, JDO and Hibernate data access
technology. It supports Hessian, Burlap, JAX-RPC and RMI remoting. I don't
think any of this has proved to be a problem. It supports JSP, Freemarker
and Velocity, and I can't remember anyone asking which was the "official"
spring view technology. Aren't we fighting windmills here?

I must admit that I find the Apache Commons validator an infuriating product
because it is pretty good in some ways and absolutely horrible in others,
and I would look forward to a clean, flexible and pluggable native Spring
solution. Until then it seems to me that a validator adapter fits entirely
into the Spring philosophy as it stands.

 - Peter

[Springframework-developer] re: Keep Spring Focused

[Larry M. <Lar...@pl...>]

I tend to agree with Bradon on this. Look at the success of OS tools
like linux, eclipse, and netbeans - the reason these are so powerful and
widely used is not because the include everything, but because they CAN.

When you get a linux distro, it comes with the ability to easily include
any of several flavors of logging or cron, not just vixie-cron and
metalog (unlike it's leading non-OS counterpart which comes as a 3000
pound gorilla).

Why? Because the people developing and distributing linux understand
that both ease of use *and* weight are important to their user base.

I hope that the same can be said for the spring team.

Larry

Re: [Springframework-developer] Creating documentation from Spring beans definition files (e.g. like HiveMind's HiveDoc)

[Daniel P. <po...@ci...>]

I know it's not quite what you had in mind with this question, but we've
used Graphviz (www.research.att.com/sw/tools/graphviz/) to
generate dependency graphs based on Spring configuration files.  The
basic process involves using an XSL stylesheet to transform the Spring
XML config files into the .dot syntax used by Graphviz, then running
Graphviz on the .dot files to generate png, gif, postscript, etc.
dependency graphs.  Of course, this wouldn't work for autowired
configurations, but it generates interesting and useful graphs for
explicit configurations.

Daniel

On Tue, Apr 06, 2004 at 01:02:39AM -0700, Torsten Juergeleit wrote:
> Is anyone already working on a way to create
> documentation from Spring beans definition files?
> 
> Howard's HiveMind / HiveDoc
> (http://jakarta.apache.org/hivemind/hivedoc.html) uses
> XSL stylesheets to transform the HiveMind config files
> into a set of HTML files. Sample output:
> http://jakarta.apache.org/hivemind/hivedocs/index.html
> 
> Does it make sense to create something similar for
> Spring?
> 
> Torsten
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway 
> http://promotions.yahoo.com/design_giveaway/
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Keep Spring Focused WAS: commons-validator adapter

[Brandon G. <ma...@ph...>]

Here is a summary of the previous threads that lead up to this discussion.
Please read an comment.

--- Brandon Goodin Mon 4/6/2004 ---

Do what you like. But, these are the same kind of near sighted arguments
I've heard from the Struts group over the last 2 years. If you provide
integrated support for commons validator NOW people will grow to be used to
it as "the Spring" solution. Then when you introduce the "real" Spring
declarative validation you will have competing products within the framework
creating confusion. If commons validator is NOT going to be the "official"
Spring declarative validation then keep it OUT of the core distro. I do not
believe you are keeping focused in doing these type of things. You CAN
support things and help to keep them focused WITHOUT making it part of the
core. Use a little collaboration for goodness sakes.

Brandon

--- Keith Donald Mon 4/6/2004 ---

Spring to me is about making it easier to build real applications quicker.
Since most applications (mine included) demand syntax and semantic
validation of business objects, I would argue a good declarative validation
framework managed by the Spring team is a good fit.  Personally, I don't
think commons-validator is that answer for us long term.  I think we can
offer better and do so in a "cleaner" (more true Spring) fashion, and that's
the focus of the 1.1 declarative validation efforts.  However, we recognize
a substantial number of people out there already have an investment in
Struts/commons-validator--thus for us to provide a  _thin_ adapter for it
that facilitates integration with the rest of Spring helps those people.
And taking responsiblity for managing that piece helps ensure it stays
consistent with the rest of the framework in terms of quality (including
documentation and test coverage.)

So my point is when I see that the Spring team has taken responsibility for
an area and put their name on it, that says something about its quality:
that is, that it is useful for one (it addresses a need, is documented, is
tested), and that it will be managed and supported carefully over time.  Rod
and Juergen are not going to move something out of the sandbox into the core
and into a release without first making sure it's ready and there is a real
need for it, for example.

We wouldn't want the emergence of a ton of decentralized Spring sub projects
to produce a sourceforge-like effect over time--that is, a lot of projects
that are inconsistent in terms of support-level/documentation/activity, etc
(and personally I prefer Spring as my one-stop-shop, reducing the headache
generally associated with managing technology integration [even then though,
it's still modular...]).   Please note this is not to say subprojects that
leverage Spring are a bad idea!  Heck no, just look at the new Acegi
Security Framework, for example!  There just needs to be a separation
between _what is_ Spring and what is a _separately managed_ project that
builds on Spring.

I agree we don't need a million validator options, and we should say "no" to
things that aren't a good fit or don't address a clear, substantial user
need.  So again the goal here is to allow those already with an investment
in commons-validator or Struts a way to easily integrate it with Spring.
The adapter is to be quite thin and optional and there for people wanting to
use Spring but also needing it.  Long term, I'd like to see everyone using
our own declarative validation stuff that we're working on now, because we
feel we can offer something better and with some unique capabilities.  But
it's not ready yet (and even if it was people can't be expected to migrate
everything on a dime, right?)

Keith

--- Brandon Goodin Mon 4/5/2004 ---

This is exactly what I mean. Thanks Karl. I hope developers of Spring take
what Karl is saying to heart. To me this is vitally important in keeping the
reality and perception of Spring light and focused. I would hate to see
Spring suffer from what Struts suffers from... "fascination with gadgetry"
or BSOS (Bright Shiny Object Syndrome)...distraction from what is important.

Any developers reading this?

Brandon

--- Karl Baum Mon 4/5/2004 ---

It's great that Spring offers a developer so many options, but after a while
it may be difficult to separate core Spring from the convenient add ons.
What must a developer read up on before he or she understands what spring is
really about?  I would tend to side towards IOC, AOP, and the BeanFactory
before the commons validator plugin, but this does not mean a commons
validator plugin is not a great idea (I for one am trying to integrate it
into my current project.).  Each plugin that is integrated directly into the
project is yet another responsibility for the community of Spring developers
when it comes to documentation and maintenance.  This documentation, with
all of the add ons and plugins, will eventually become so bloated, the
average developer may become overwhelmed by it's size and complexity.

Why not farm these plugins out to smaller subprojects with teams of
developers focused on delivering a specific add on to the Spring project.
This leaves everyone with all of the great Spring options, but in the end
the Spring Framework never loses site of it's purpose  This isn't just about
the commons validator project.  With each new popular open source component,
we will need yet another package checked into the Spring project.  We can
start now with the spring-commons-validator subproject.

--- Brandon Goodin Mon 4/5/2004 ---

I understand that. I'm simply saying... leave the choices on other websites
and focus on what spring is. Not on all the neat toys you can plug into it.
So, where do you draw the line on what does and does not get included. Why
not setup a directory of tools that can be used in spring instead of feeling
compelled to include support for every permutation into the distro or in the
spring cvs. Just cuz you can doesn't mean you should. I think moves like
this will cause confusion around spring not help it.

Brandon

--- Seth Ladd Mon 4/5/2004 ---

A nice aspect of Spring is that it attempts to give developers different
choices for a particular task.  For validation, commons-validator is just
one choice.  Other choices include metadata validator or programmatic
validation.  IMHO, the commons-validator fills a nice
niche: when you want to do declarative validation but can't mark up the
source code (if, for example, you're using generated source or 3rd party
classes).

With Spring, you get to Pick and Choose!
Seth.

RE: [Springframework-developer] RE: commons-validator adapter

[Brandon G. <ma...@ph...>]

This is not a bash struts thread. It worked for it's season. This is a
"please keep Spring focused" thread. Please, focus your comments towards
that effort.

Brandon

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Colin Sampaleanu
Sent: Tuesday, April 06, 2004 6:52 AM
To: spr...@li...
Subject: Re: [Springframework-developer] RE: commons-validator adapter

Putting on my pundit cap, some people might say the what Struts suffers 
most from is bad design :-)

Brandon Goodin wrote:

>This is exactly what I mean. Thanks Karl. I hope developers of Spring take
>what Karl is saying to heart. To me this is vitally important in keeping
the
>reality and perception of Spring light and focused. I would hate to see
>Spring suffer from what Struts suffers from... "fascination with gadgetry"
>or BSOS (Bright Shiny Object Syndrome)...distraction from what is
important.
>
>Any developers reading this?
>
>Brandon
>
>P.S. How are you doing Karl? :D Haven't talked to you since struts-chain. I
>bailed on it in hopes of what Spring is offering.
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Baum, Karl
>Sent: Monday, April 05, 2004 8:33 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] RE: commons-validator adapter
>
>It's great that Spring offers a developer so many options, but after a
while
>it may be difficult to separate core Spring from the convenient add ons.
>What must a developer read up on before he or she understands what spring
is
>really about?  I would tend to side towards IOC, AOP, and the BeanFactory
>before the commons validator plugin, but this does not mean a commons
>validator plugin is not a great idea (I for one am trying to integrate it
>into my current project.).  Each plugin that is integrated directly into
the
>project is yet another responsibility for the community of Spring
developers
>when it comes to documentation and maintenance.  This documentation, with
>all of the add ons and plugins, will eventually become so bloated, the
>average developer may become overwhelmed by it's size and complexity.
>
>Why not farm these plugins out to smaller subprojects with teams of
>developers focused on delivering a specific add on to the Spring project.
>This leaves everyone with all of the great Spring options, but in the end
>the Spring Framework never loses site of it's purpose  This isn't just
about
>the commons validator project.  With each new popular open source
component,
>we will need yet another package checked into the Spring project.  We can
>start now with the spring-commons-validator subproject.
>
>----- Original Message -----
>From: "Brandon Goodin" <ma...@ph...>
>To: <spr...@li...>
>Sent: Monday, April 05, 2004 10:08 PM
>Subject: RE: [Springframework-developer] RE: commons-validator adapter
>
>
>  
>
>>I understand that. I'm simply saying... leave the choices on other
>>    
>>
>websites
>  
>
>>and focus on what spring is. Not on all the neat toys you can plug into
>>    
>>
>it.
>  
>
>>So, where do you draw the line on what does and does not get included. Why
>>not setup a directory of tools that can be used in spring instead of
>>    
>>
>feeling
>  
>
>>compelled to include support for every permutation into the distro or in
>>    
>>
>the
>  
>
>>spring cvs. Just cuz you can doesn't mean you should. I think moves like
>>this will cause confusion around spring not help it.
>>
>>B
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On Behalf
>>    
>>
>Of
>  
>
>>Seth Ladd
>>Sent: Monday, April 05, 2004 5:29 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] RE: commons-validator adapter
>>
>>Brandon Goodin wrote:
>>    
>>
>>>commons validator? gack! Don't pollute spring with all of this crap. I
>>>don't want to see spring turn into the 8000 pound gorilla that struts
>>>has. Please consider making this stuff peripheral.
>>>      
>>>
>>A nice aspect of Spring is that it attempts to give developers different
>>choices for a particular task.  For validation, commons-validator is
>>just one choice.  Other choices include metadata validator or
>>programmatic validation.  IMHO, the commons-validator fills a nice
>>niche: when you want to do declarative validation but can't mark up the
>>source code (if, for example, you're using generated source or 3rd party
>>classes).
>>
>>With Spring, you get to Pick and Choose!
>>Seth
>>    
>>



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] RE: commons-validator adapter

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

Putting on my pundit cap, some people might say the what Struts suffers 
most from is bad design :-)

Brandon Goodin wrote:

>This is exactly what I mean. Thanks Karl. I hope developers of Spring take
>what Karl is saying to heart. To me this is vitally important in keeping the
>reality and perception of Spring light and focused. I would hate to see
>Spring suffer from what Struts suffers from... "fascination with gadgetry"
>or BSOS (Bright Shiny Object Syndrome)...distraction from what is important.
>
>Any developers reading this?
>
>Brandon
>
>P.S. How are you doing Karl? :D Haven't talked to you since struts-chain. I
>bailed on it in hopes of what Spring is offering.
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Baum, Karl
>Sent: Monday, April 05, 2004 8:33 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] RE: commons-validator adapter
>
>It's great that Spring offers a developer so many options, but after a while
>it may be difficult to separate core Spring from the convenient add ons.
>What must a developer read up on before he or she understands what spring is
>really about?  I would tend to side towards IOC, AOP, and the BeanFactory
>before the commons validator plugin, but this does not mean a commons
>validator plugin is not a great idea (I for one am trying to integrate it
>into my current project.).  Each plugin that is integrated directly into the
>project is yet another responsibility for the community of Spring developers
>when it comes to documentation and maintenance.  This documentation, with
>all of the add ons and plugins, will eventually become so bloated, the
>average developer may become overwhelmed by it's size and complexity.
>
>Why not farm these plugins out to smaller subprojects with teams of
>developers focused on delivering a specific add on to the Spring project.
>This leaves everyone with all of the great Spring options, but in the end
>the Spring Framework never loses site of it's purpose  This isn't just about
>the commons validator project.  With each new popular open source component,
>we will need yet another package checked into the Spring project.  We can
>start now with the spring-commons-validator subproject.
>
>----- Original Message -----
>From: "Brandon Goodin" <ma...@ph...>
>To: <spr...@li...>
>Sent: Monday, April 05, 2004 10:08 PM
>Subject: RE: [Springframework-developer] RE: commons-validator adapter
>
>
>  
>
>>I understand that. I'm simply saying... leave the choices on other
>>    
>>
>websites
>  
>
>>and focus on what spring is. Not on all the neat toys you can plug into
>>    
>>
>it.
>  
>
>>So, where do you draw the line on what does and does not get included. Why
>>not setup a directory of tools that can be used in spring instead of
>>    
>>
>feeling
>  
>
>>compelled to include support for every permutation into the distro or in
>>    
>>
>the
>  
>
>>spring cvs. Just cuz you can doesn't mean you should. I think moves like
>>this will cause confusion around spring not help it.
>>
>>B
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On Behalf
>>    
>>
>Of
>  
>
>>Seth Ladd
>>Sent: Monday, April 05, 2004 5:29 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] RE: commons-validator adapter
>>
>>Brandon Goodin wrote:
>>    
>>
>>>commons validator? gack! Don't pollute spring with all of this crap. I
>>>don't want to see spring turn into the 8000 pound gorilla that struts
>>>has. Please consider making this stuff peripheral.
>>>      
>>>
>>A nice aspect of Spring is that it attempts to give developers different
>>choices for a particular task.  For validation, commons-validator is
>>just one choice.  Other choices include metadata validator or
>>programmatic validation.  IMHO, the commons-validator fills a nice
>>niche: when you want to do declarative validation but can't mark up the
>>source code (if, for example, you're using generated source or 3rd party
>>classes).
>>
>>With Spring, you get to Pick and Choose!
>>Seth
>>    
>>

RE: [Springframework-developer] RE: commons-validator adapter

[Brandon G. <ma...@ph...>]

Do what you like. But, these are the same kind of near sighted arguments
I've heard from the Struts group over the last 2 years. If you provide
integrated support for commons validator NOW people will grow to be used to
it as "the Spring" solution. Then when you introduce the "real" Spring
declarative validation you will have competing products within the framework
creating confusion. If commons validator is NOT going to be the "official"
Spring declarative validation then keep it OUT of the core distro. I do not
believe you are keeping focused in doing these type of things. You CAN
support things and help to keep them focused WITHOUT making it part of the
core. Use a little collaboration for goodness sakes.

Brandon

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Keith Donald
Sent: Tuesday, April 06, 2004 1:02 AM
To: spr...@li...
Subject: Re: [Springframework-developer] RE: commons-validator adapter

Spring to me is about making it easier to build real applications quicker.
Since most applications (mine included) demand syntax and semantic
validation of business objects, I would argue a good declarative validation
framework managed by the Spring team is a good fit.  Personally, I don't
think commons-validator is that answer for us long term.  I think we can
offer better and do so in a "cleaner" (more true Spring) fashion, and that's
the focus of the 1.1 declarative validation efforts.  However, we recognize
a substantial number of people out there already have an investment in
Struts/commons-validator--thus for us to provide a  _thin_ adapter for it
that facilitates integration with the rest of Spring helps those people.
And taking responsiblity for managing that piece helps ensure it stays
consistent with the rest of the framework in terms of quality (including
documentation and test coverage.)

So my point is when I see that the Spring team has taken responsibility for
an area and put their name on it, that says something about its quality:
that is, that it is useful for one (it addresses a need, is documented, is
tested), and that it will be managed and supported carefully over time.  Rod
and Juergen are not going to move something out of the sandbox into the core
and into a release without first making sure it's ready and there is a real
need for it, for example.

We wouldn't want the emergence of a ton of decentralized Spring sub projects
to produce a sourceforge-like effect over time--that is, a lot of projects
that are inconsistent in terms of support-level/documentation/activity, etc
(and personally I prefer Spring as my one-stop-shop, reducing the headache
generally associated with managing technology integration [even then though,
it's still modular...]).   Please note this is not to say subprojects that
leverage Spring are a bad idea!  Heck no, just look at the new Acegi
Security Framework, for example!  There just needs to be a separation
between _what is_ Spring and what is a _separately managed_ project that
builds on Spring.

I agree we don't need a million validator options, and we should say "no" to
things that aren't a good fit or don't address a clear, substantial user
need.  So again the goal here is to allow those already with an investment
in commons-validator or Struts a way to easily integrate it with Spring.
The adapter is to be quite thin and optional and there for people wanting to
use Spring but also needing it.  Long term, I'd like to see everyone using
our own declarative validation stuff that we're working on now, because we
feel we can offer something better and with some unique capabilities.  But
it's not ready yet (and even if it was people can't be expected to migrate
everything on a dime, right?)

Keith

----- Original Message ----- 
From: "Brandon Goodin" <ma...@ph...>
To: <spr...@li...>
Sent: Monday, April 05, 2004 10:08 PM
Subject: RE: [Springframework-developer] RE: commons-validator adapter


> I understand that. I'm simply saying... leave the choices on other
websites
> and focus on what spring is. Not on all the neat toys you can plug into
it.
> So, where do you draw the line on what does and does not get included. Why
> not setup a directory of tools that can be used in spring instead of
feeling
> compelled to include support for every permutation into the distro or in
the
> spring cvs. Just cuz you can doesn't mean you should. I think moves like
> this will cause confusion around spring not help it.
>
> B
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
Of
> Seth Ladd
> Sent: Monday, April 05, 2004 5:29 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] RE: commons-validator adapter
>
> Brandon Goodin wrote:
> > commons validator? gack! Don't pollute spring with all of this crap. I
> > don't want to see spring turn into the 8000 pound gorilla that struts
> > has. Please consider making this stuff peripheral.
>
>
> A nice aspect of Spring is that it attempts to give developers different
> choices for a particular task.  For validation, commons-validator is
> just one choice.  Other choices include metadata validator or
> programmatic validation.  IMHO, the commons-validator fills a nice
> niche: when you want to do declarative validation but can't mark up the
> source code (if, for example, you're using generated source or 3rd party
> classes).
>
> With Spring, you get to Pick and Choose!
> Seth
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Creating documentation from Spring beans definition files (e.g. like HiveMind's HiveDoc)

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

> Torsten
>
> Yes, indeed it does make sense to have such a tool for
> Spring. This is a nice feature of Hivemind. I added this as
> an issue in Jira a couple of weeks ago.
>
> Any volunteers?
>
> Regards,
> Rod

I've thought about doing it for a while and now that a couple of my
projects at work are having a lot of the technical docs expanded, it may
be a good time to commit to it.  It would benefit me quite a lot if we ha=
d
one :)

With a new baby due any minute, it will be a while before I could get my
teeth into it so if anyone has a desperate need for one immediately, feel
free to jump in.

I'll assign the JIRA issue to myself - perhaps people could add their
specific requirements / wish list to the comments in JIRA (or through the
mailing list if you've no login) and I'll start thinking about the
implementation.

D.

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

Re: [Springframework-developer] Where's "Resolve Issue" gone in our JIRA?

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

Thanks, Mike - resolving works again now! :-)

Unfortunately, the issue browser still shows outdated associations: For =
example, I associated SPR-77 with fix version 1.0.2 last week, but it's =
still shown in the 1.1 RC1 list. Funnily enough, the overview correctly =
shows one entry for 1.0.2, but when you click at it, you'll see an empty =
list rather than SPR-77.

http://opensource.atlassian.com/projects/spring/browse/SPR-77
http://opensource.atlassian.com/projects/spring/secure/BrowseProject.jspa=


Thanks for all your efforts, they are much appreciated!

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Mike Cannon-Brookes
Sent: Tuesday, April 06, 2004 12:17 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Where's "Resolve Issue" gone in
our JIRA?


J=FCrgen,

Sorry about this - it seems (after much investigation today) that in=20
fixing your instance we also managed to break it with the previous=20
investigations. Many apologies, it should be fixed now - the errant=20
debug JAR has been removed.

I've resolved SPR-86 (to test) and it worked fine this time. I hope=20
that's OK :)

Any more problems, please do let us know.

Cheers,
Mike

--
ATLASSIAN - http://www.atlassian.com/

Confluence - the professional J2EE wiki - tried it yet?
http://www.atlassian.com/confluence/

On 06/04/2004, at 4:43 AM, j=FCrgen h=F6ller [werk3AT] wrote:

> Mike,
>
> The problem with resolving issues in our JIRA is still there.=20
> Furthermore, I've noticed that after a fix date has been set, the=20
> issue is still visible in the "unscheduled list": Funnily enough, the=20
> correct number of issues is given in the overview list, but the actual =

> list of issues is outdated.
>
> As I'd like to resolve all fixed issues for the upcoming Spring=20
> release 1.0.1, I'd really appreciate if "resolve issue" would work=20
> again :-)
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag=20
> von j=FCrgen h=F6ller [werk3AT]
> Gesendet: Di 30.03.2004 15:51
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Where's "Resolve Issue" gone=20
> in our JIRA?
>
>
>
> I still can't resolve issues (for example SPR-86), getting:
>
>   Form Errors:
>   Action 1 is invalid
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Mike Cannon-Brookes
> Sent: Tuesday, March 30, 2004 3:06 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Where's "Resolve Issue" gone=20
> in
> our JIRA?
>
>
> Apologies for this guys - we upgraded all the Open Source JIRA
> instances as well as moving them to a new, much faster box (you can =
see
> the speed increase!). The Spring workflow had some problems, but those
> should all be ironed out now.
>
> There are plenty of fun new things to play with in 2.6.1 and 2.6 - see
> here for full details:
>
>     =
http://confluence.atlassian.com/display/JIRA/JIRA+2.6+Release+Notes
>
> Any further problems, please let me know - you can always contact me
> via IM at any time, details:
>
>     http://confluence.atlassian.com/display/~mi...@at...
>
> Cheers,
> Mike
>
> --
> ATLASSIAN - http://www.atlassian.com/
>
> Confluence - the professional J2EE wiki - tried it yet?
> http://www.atlassian.com/confluence/
>
> On 27/03/2004, at 12:03 AM, Dmitriy Kopylenko wrote:
>
>> Ahhhhhhhhh Juergen, I noticed something.... I looked at the bottom of
>> the
>> screen and I saw: "Enterprise Edition, Version: 2.6.1-#65" We've been
>> running 2.5 before. Looks like they've upgraded to the latest =
version.
>> Something must have changed.
>>
>> Mike, do you know what the problem might be? Also when I tried to
>> assign any
>> issue "to me", I got a stack trace screen.
>>
>> Regards,
>> Dmitriy.
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On
>> Behalf Of
>> j=FCrgen h=F6ller [werk3AT]
>> Sent: Friday, March 26, 2004 3:36 AM
>> To: spr...@li...
>> Subject: [Springframework-developer] Where's "Resolve Issue" gone in
>> our
>> JIRA?
>>
>>
>> For some odd reason, "Resolve Issue"  is not available in our JIRA.=20
>> All
>> administration options are available to me, so I wonder whether this
>> is a
>> problem with my account or with JIRA. It did work until Wednesday; at
>> least
>> I've not noted any problems.
>>
>> 2 of the 3 issues I've fixed for 1.0.1 are ready to be closed; I =
can't
>> do
>> this without a "resolve" command...
>>
>> Juergen
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IBM Linux Tutorials
>> Free Linux tutorial presented by Daniel Robbins, President and CEO of
>> GenToo
>> technologies. Learn everything from fundamentals to system
>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IBM Linux Tutorials
>> Free Linux tutorial presented by Daniel Robbins, President and CEO of
>> GenToo technologies. Learn everything from fundamentals to system
>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Where's "Resolve Issue" gone in our JIRA?

[Mike Cannon-B. <mi...@at...>]

J=FCrgen,

Sorry about this - it seems (after much investigation today) that in=20
fixing your instance we also managed to break it with the previous=20
investigations. Many apologies, it should be fixed now - the errant=20
debug JAR has been removed.

I've resolved SPR-86 (to test) and it worked fine this time. I hope=20
that's OK :)

Any more problems, please do let us know.

Cheers,
Mike

--
ATLASSIAN - http://www.atlassian.com/

Confluence - the professional J2EE wiki - tried it yet?
http://www.atlassian.com/confluence/

On 06/04/2004, at 4:43 AM, j=FCrgen h=F6ller [werk3AT] wrote:

> Mike,
>
> The problem with resolving issues in our JIRA is still there.=20
> Furthermore, I've noticed that after a fix date has been set, the=20
> issue is still visible in the "unscheduled list": Funnily enough, the=20=

> correct number of issues is given in the overview list, but the actual=20=

> list of issues is outdated.
>
> As I'd like to resolve all fixed issues for the upcoming Spring=20
> release 1.0.1, I'd really appreciate if "resolve issue" would work=20
> again :-)
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag=20=

> von j=FCrgen h=F6ller [werk3AT]
> Gesendet: Di 30.03.2004 15:51
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Where's "Resolve Issue" gone=20=

> in our JIRA?
>
>
>
> I still can't resolve issues (for example SPR-86), getting:
>
>   Form Errors:
>   Action 1 is invalid
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Mike Cannon-Brookes
> Sent: Tuesday, March 30, 2004 3:06 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Where's "Resolve Issue" gone=20=

> in
> our JIRA?
>
>
> Apologies for this guys - we upgraded all the Open Source JIRA
> instances as well as moving them to a new, much faster box (you can =
see
> the speed increase!). The Spring workflow had some problems, but those
> should all be ironed out now.
>
> There are plenty of fun new things to play with in 2.6.1 and 2.6 - see
> here for full details:
>
>     =
http://confluence.atlassian.com/display/JIRA/JIRA+2.6+Release+Notes
>
> Any further problems, please let me know - you can always contact me
> via IM at any time, details:
>
>     http://confluence.atlassian.com/display/~mi...@at...
>
> Cheers,
> Mike
>
> --
> ATLASSIAN - http://www.atlassian.com/
>
> Confluence - the professional J2EE wiki - tried it yet?
> http://www.atlassian.com/confluence/
>
> On 27/03/2004, at 12:03 AM, Dmitriy Kopylenko wrote:
>
>> Ahhhhhhhhh Juergen, I noticed something.... I looked at the bottom of
>> the
>> screen and I saw: "Enterprise Edition, Version: 2.6.1-#65" We've been
>> running 2.5 before. Looks like they've upgraded to the latest =
version.
>> Something must have changed.
>>
>> Mike, do you know what the problem might be? Also when I tried to
>> assign any
>> issue "to me", I got a stack trace screen.
>>
>> Regards,
>> Dmitriy.
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On
>> Behalf Of
>> j=FCrgen h=F6ller [werk3AT]
>> Sent: Friday, March 26, 2004 3:36 AM
>> To: spr...@li...
>> Subject: [Springframework-developer] Where's "Resolve Issue" gone in
>> our
>> JIRA?
>>
>>
>> For some odd reason, "Resolve Issue"  is not available in our JIRA.=20=

>> All
>> administration options are available to me, so I wonder whether this
>> is a
>> problem with my account or with JIRA. It did work until Wednesday; at
>> least
>> I've not noted any problems.
>>
>> 2 of the 3 issues I've fixed for 1.0.1 are ready to be closed; I =
can't
>> do
>> this without a "resolve" command...
>>
>> Juergen
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IBM Linux Tutorials
>> Free Linux tutorial presented by Daniel Robbins, President and CEO of
>> GenToo
>> technologies. Learn everything from fundamentals to system
>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IBM Linux Tutorials
>> Free Linux tutorial presented by Daniel Robbins, President and CEO of
>> GenToo technologies. Learn everything from fundamentals to system
>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Creating documentation from Spring beans definition files (e.g. like HiveMind's HiveDoc)

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

Torsten

Yes, indeed it does make sense to have such a tool for 
Spring. This is a nice feature of Hivemind. I added this as 
an issue in Jira a couple of weeks ago.

Any volunteers?

Regards,
Rod

[Springframework-developer] Creating documentation from Spring beans definition files (e.g. like HiveMind's HiveDoc)

[Torsten J. <tju...@ya...>]

Is anyone already working on a way to create
documentation from Spring beans definition files?

Howard's HiveMind / HiveDoc
(http://jakarta.apache.org/hivemind/hivedoc.html) uses
XSL stylesheets to transform the HiveMind config files
into a set of HTML files. Sample output:
http://jakarta.apache.org/hivemind/hivedocs/index.html

Does it make sense to create something similar for
Spring?

Torsten

__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

Re: [Springframework-developer] RE: commons-validator adapter

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

Spring to me is about making it easier to build real applications quicker.
Since most applications (mine included) demand syntax and semantic
validation of business objects, I would argue a good declarative validation
framework managed by the Spring team is a good fit.  Personally, I don't
think commons-validator is that answer for us long term.  I think we can
offer better and do so in a "cleaner" (more true Spring) fashion, and that's
the focus of the 1.1 declarative validation efforts.  However, we recognize
a substantial number of people out there already have an investment in
Struts/commons-validator--thus for us to provide a  _thin_ adapter for it
that facilitates integration with the rest of Spring helps those people.
And taking responsiblity for managing that piece helps ensure it stays
consistent with the rest of the framework in terms of quality (including
documentation and test coverage.)

So my point is when I see that the Spring team has taken responsibility for
an area and put their name on it, that says something about its quality:
that is, that it is useful for one (it addresses a need, is documented, is
tested), and that it will be managed and supported carefully over time.  Rod
and Juergen are not going to move something out of the sandbox into the core
and into a release without first making sure it's ready and there is a real
need for it, for example.

We wouldn't want the emergence of a ton of decentralized Spring sub projects
to produce a sourceforge-like effect over time--that is, a lot of projects
that are inconsistent in terms of support-level/documentation/activity, etc
(and personally I prefer Spring as my one-stop-shop, reducing the headache
generally associated with managing technology integration [even then though,
it's still modular...]).   Please note this is not to say subprojects that
leverage Spring are a bad idea!  Heck no, just look at the new Acegi
Security Framework, for example!  There just needs to be a separation
between _what is_ Spring and what is a _separately managed_ project that
builds on Spring.

I agree we don't need a million validator options, and we should say "no" to
things that aren't a good fit or don't address a clear, substantial user
need.  So again the goal here is to allow those already with an investment
in commons-validator or Struts a way to easily integrate it with Spring.
The adapter is to be quite thin and optional and there for people wanting to
use Spring but also needing it.  Long term, I'd like to see everyone using
our own declarative validation stuff that we're working on now, because we
feel we can offer something better and with some unique capabilities.  But
it's not ready yet (and even if it was people can't be expected to migrate
everything on a dime, right?)

Keith

----- Original Message ----- 
From: "Brandon Goodin" <ma...@ph...>
To: <spr...@li...>
Sent: Monday, April 05, 2004 10:08 PM
Subject: RE: [Springframework-developer] RE: commons-validator adapter


> I understand that. I'm simply saying... leave the choices on other
websites
> and focus on what spring is. Not on all the neat toys you can plug into
it.
> So, where do you draw the line on what does and does not get included. Why
> not setup a directory of tools that can be used in spring instead of
feeling
> compelled to include support for every permutation into the distro or in
the
> spring cvs. Just cuz you can doesn't mean you should. I think moves like
> this will cause confusion around spring not help it.
>
> B
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
Of
> Seth Ladd
> Sent: Monday, April 05, 2004 5:29 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] RE: commons-validator adapter
>
> Brandon Goodin wrote:
> > commons validator? gack! Don't pollute spring with all of this crap. I
> > don't want to see spring turn into the 8000 pound gorilla that struts
> > has. Please consider making this stuff peripheral.
>
>
> A nice aspect of Spring is that it attempts to give developers different
> choices for a particular task.  For validation, commons-validator is
> just one choice.  Other choices include metadata validator or
> programmatic validation.  IMHO, the commons-validator fills a nice
> niche: when you want to do declarative validation but can't mark up the
> source code (if, for example, you're using generated source or 3rd party
> classes).
>
> With Spring, you get to Pick and Choose!
> Seth
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Groovy / Jython (was: Road map)

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

Indeed, a BeanFactory is the container while BeanDefinitionReaders are =
able to parse specific bean definition formats into a BeanFactory. This =
is strictly separated since 1.0 M4, IIRC. Obviously, you have to deal =
with a factory instance and a reader instance here, and also do the =
appropriate initialization calls: A BeanFactory and =
BeanDefinitionReaders are meant to be used in a programmatic fashion.
=20
XmlBeanFactory is just a convenient one-stop shop that combines =
DefaultListableBeanFactory and DefaultXmlBeanDefinitionReader. It's also =
still there for backward compatibility, but I guess it makes sense to =
keep it, as it's easy to use, and XML is still the dominant bean =
definition format. I don't think that we need any further convenience =
BeanFactory: For new formats, there should just be a =
BeanDefinitionReader.
=20
A concrete ApplicationContext implementation is supposed to have a fixed =
underlying BeanFactory. XmlWebApplicationContext, =
FileSystemXmlApplicationContext and ClassPathXmlApplicationContext are =
such implementations for XML bean definitions and a concrete runtime =
environment: They are as easy to use as an XmlBeanFactory, also =
providing one-stop shops.
=20
A custom ApplicationContext implementation is not hard to do: Derive =
from AbstractApplicationContext and implement its callbacks for a =
concrete underlying BeanFactory. Basically, you'll set up and populate =
the BeanFactory in refreshBeanFactory() and make it accessible via =
getBeanFactory(). You can use any ConfigurableListableBeanFactory =
implementation there, and of course any BeanDefinitionReaders.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Alef Arendsen
Gesendet: Mo 05.04.2004 23:42
An: spr...@li...
Betreff: RE: [Springframework-developer] Groovy / Jython (was: Road map)



What about the separation between BeanDefinitionReaders and =
BeanFactories? I
thought BeanDefinitionReaders were supposed to do the stuff specific to =
the
format (say XML or properties) and BeanFactory is just the container. =
But
that's confusing because there still is a *Xml*BeanFactory out there.

J=FCrgen, what's your take on this? Is the XmlBeanFactory and =
XmlWebAppCtx
something ancient or does it still have its use?

Alef


> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of Thomas Risberg
> Sent: Sunday, April 04, 2004 10:35 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Groovy / Jython (was: Road =
map)
>
> I have bee experimenting a bit with Jython.  I have not used it for a
> while, so I'm a bit rusty, but I did load an application context and
> used a data source been that was defined in it.
>
> I think that the different types of bean factories are going to have
> different feature sets - property files are less feature rich than the
> xml files.  With jython and groovy, we will have similar issues where
> some features just does not fit naturally.
>
> Here is my context (applicationContext.py):
>
> from org.springframework.jdbc.datasource import =
DriverManagerDataSource
> from org.springframework.jdbc.core import JdbcTemplate
>
> dataSource =3D DriverManagerDataSource()
> dataSource.driverClassName=3D"org.hsqldb.jdbcDriver"
> dataSource.url=3D"jdbc:hsqldb:hsql://localhost"
> dataSource.username=3D"sa"
> dataSource.password=3D""
>
> db =3D JdbcTemplate(dataSource)
>
>
> Here is my code (LoadPyContext.java:
>
> import java.util.List;
>
> import org.python.core.PySystemState;
> import org.python.util.PythonInterpreter;
> import org.springframework.jdbc.core.JdbcTemplate;
>
> public class LoadPyContext {
>     public static void main(String[] args) {
>         System.out.println("Start");
>         PySystemState.initialize();
>         PythonInterpreter pyInterp =3D new PythonInterpreter();
>         pyInterp.execfile("applicationContext.py");
>         JdbcTemplate db =3D (JdbcTemplate) pyInterp.get("db",
> JdbcTemplate.class);
>         List l =3D db.queryForList("select brand, price from beer");
>         System.out.println(l);
>     }
> }
>
> I guess the next step is to actually create a PythonBeanFactory.
>
> Thomas
>
> Alef Arendsen wrote:
>
> >Err,
> >
> >Been able to get a beanfactory up-and-running, however, not in a way =
as
> >elegant as I wanted it to be, but that's something that's probably =
going
> to
> >take some more time and thinking. It's something like this, and I =
don't
> like
> >it ;-)
> >
> >test =3D new BeanDef (age:8,name:'susan')
> >test.singleton =3D true
> >test.dependencyCheck =3D PRIMITIVES
> >
> >est =3D new BeanDef (age:10)
> >est.name=3D'jim'
> >est.spouse=3Dtest
> >est.singleton =3D false
> >
> >I'm not entirely sure how to go about the dependencies and properties =
of
> a
> >bean versus the behavioral stuff (singleton, dependency checking,
> etcetera).
> >For sure we need some extra stuff here (i.e. some kind of wrapper =
around
> the
> >BeanDefinition class--the BeanDef class in the script above), I don't
> think
> >dealing with MutablePropertyValue objects in a Groovy script directly =
is
> the
> >way to go. But maybe you noticed the problem in the script above =
already:
> >you can't have dependencies named 'singleton' or 'dependencyCheck' =
here.
> So
> >maybe including some kind of metadata object might be an option.
> >
> >By the way, from my point of view, there's a difference between =
reading
> in
> >and modifying a applicationcontext and its beandefinition and =
actually
> >approaching/using it at runtime. Currently I'm only thinking about =
the
> >former... Using it from Groovy scripts however could be quite =
something
> as
> >well!
> >
> >Regards,
> >Alef
> >
> >
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: spr...@li...
> >>[mailto:spr...@li...] On =
Behalf
> >>Of Darren Davison
> >>Sent: Saturday, April 03, 2004 1:01 PM
> >>To: spr...@li...
> >>Subject: [Springframework-developer] Groovy / Jython (was: Road map)
> >>
> >>On Saturday 03 April 2004 09:47, Alef Arendsen wrote:
> >>
> >>
> >>
> >>>It would be nice to have something in the sandbox indeed. I'm =
currently
> >>>experimenting with a GroovyBeanDefinitionReader and it seems it's =
not
> >>>going to be all that tough to get it running!
> >>>
> >>>
> >>snap!
> >>
> >>I started looking at something similar in both Groovy and Jython =
(partly
> >>to
> >>see which of those two was 'best').  Thought it may be very useful =
for
> >>writing tests or certain deployment scripts.
> >>
> >>How far have you got with it?
> >>
> >>--
> >>
> >>Darren Davison
> >>Public Key: http://www.davison.uk.net/key.jsp
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by: IBM Linux Tutorials
> >>Free Linux tutorial presented by Daniel Robbins, President and CEO =
of
> >>GenToo technologies. Learn everything from fundamentals to system
> =
>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> >>_______________________________________________
> >>Springframework-developer mailing list
> >>Spr...@li...
> =
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: IBM Linux Tutorials
> >Free Linux tutorial presented by Daniel Robbins, President and CEO of
> >GenToo technologies. Learn everything from fundamentals to system
> >administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> >_______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
> =
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] RE: commons-validator adapter

[Brandon G. <ma...@ph...>]

This is exactly what I mean. Thanks Karl. I hope developers of Spring take
what Karl is saying to heart. To me this is vitally important in keeping the
reality and perception of Spring light and focused. I would hate to see
Spring suffer from what Struts suffers from... "fascination with gadgetry"
or BSOS (Bright Shiny Object Syndrome)...distraction from what is important.

Any developers reading this?

Brandon

P.S. How are you doing Karl? :D Haven't talked to you since struts-chain. I
bailed on it in hopes of what Spring is offering.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Baum, Karl
Sent: Monday, April 05, 2004 8:33 PM
To: spr...@li...
Subject: Re: [Springframework-developer] RE: commons-validator adapter

It's great that Spring offers a developer so many options, but after a while
it may be difficult to separate core Spring from the convenient add ons.
What must a developer read up on before he or she understands what spring is
really about?  I would tend to side towards IOC, AOP, and the BeanFactory
before the commons validator plugin, but this does not mean a commons
validator plugin is not a great idea (I for one am trying to integrate it
into my current project.).  Each plugin that is integrated directly into the
project is yet another responsibility for the community of Spring developers
when it comes to documentation and maintenance.  This documentation, with
all of the add ons and plugins, will eventually become so bloated, the
average developer may become overwhelmed by it's size and complexity.

Why not farm these plugins out to smaller subprojects with teams of
developers focused on delivering a specific add on to the Spring project.
This leaves everyone with all of the great Spring options, but in the end
the Spring Framework never loses site of it's purpose  This isn't just about
the commons validator project.  With each new popular open source component,
we will need yet another package checked into the Spring project.  We can
start now with the spring-commons-validator subproject.

----- Original Message -----
From: "Brandon Goodin" <ma...@ph...>
To: <spr...@li...>
Sent: Monday, April 05, 2004 10:08 PM
Subject: RE: [Springframework-developer] RE: commons-validator adapter


> I understand that. I'm simply saying... leave the choices on other
websites
> and focus on what spring is. Not on all the neat toys you can plug into
it.
> So, where do you draw the line on what does and does not get included. Why
> not setup a directory of tools that can be used in spring instead of
feeling
> compelled to include support for every permutation into the distro or in
the
> spring cvs. Just cuz you can doesn't mean you should. I think moves like
> this will cause confusion around spring not help it.
>
> B
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
Of
> Seth Ladd
> Sent: Monday, April 05, 2004 5:29 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] RE: commons-validator adapter
>
> Brandon Goodin wrote:
> > commons validator? gack! Don't pollute spring with all of this crap. I
> > don't want to see spring turn into the 8000 pound gorilla that struts
> > has. Please consider making this stuff peripheral.
>
>
> A nice aspect of Spring is that it attempts to give developers different
> choices for a particular task.  For validation, commons-validator is
> just one choice.  Other choices include metadata validator or
> programmatic validation.  IMHO, the commons-validator fills a nice
> niche: when you want to do declarative validation but can't mark up the
> source code (if, for example, you're using generated source or 3rd party
> classes).
>
> With Spring, you get to Pick and Choose!
> Seth
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Commons-Validator for Spring

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

Thanks Daniel.  I'll try to look at this w/in the next week.  My goal 
is to convert an existing Struts app to use Spring's MVC framework with 
minimal changes.  So far, I've got Struts Menu, the DisplayTag and 
Tiles working.  All were pretty trivial.  Next up - Action to 
Controller and Validation.

I'm using XDoclet pretty heavily in my existing app - so I'm somewhat 
motivated to continue generating validation.xml from POJOs.  I'll 
probably have to hack XDoclet to make this work - since it only works 
for ValidatorForms right now.  Of course, after looking at the 
attributes stuff, they might actually be easier to use than XDoclet.  
The one advantage of XDoclet, however, is that the XML files are still 
generated, so stuff can be changed after compilation.  As far as I 
understand the attributes stuff - it'll stay hardcoded in your class 
(no XML generation).  Of course, I rarely change any of this stuff 
after compilation - but it is a nice option.

Matt


On Apr 5, 2004, at 9:58 PM, Daniel Miller wrote:

> Matt,
>
> The commons-validator adaptor for Spring is now in the sandbox on 
> sf.net. I
> would be happy to hear your comments/criticisms. The tag library is 
> totally
> separate, so you should be able to use this with any framework you 
> please,
> although it depends on a Spring BeanFactory to find the validator 
> resources.
> If there is a need, I suppose an alternative resource resolution 
> strategy
> could be implemented to remove this dependency.
>
> The actual validation classes are fairly generic as well, so you 
> shouldn't
> even need to configure Spring to use them (although you will need the 
> spring
> jar with the Validator interface in it).
>
> Thanks,
> Daniel Miller
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Matt Raible
> Sent: Thursday, March 11, 2004 11:36 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Commons-Validator for Spring
>
>
> I've used the Struts Validator for a couple years now and I think it's
> great - especially since I can generate my validation.xml using
> XDoclet.  In the coming months, I plan to learn more about Tapestry and
> WebWork.  I'd love to have a validation system that I could use on
> Struts, Spring, Tapestry and WebWork.
>
> I guess I'm saying - I'd like to see a tag library that can be used
> with other MVC frameworks.  I plan on using Spring with all these MVC
> options - so including it in the core also suits my needs.
>
> Matt
>
> On Mar 11, 2004, at 9:21 PM, Daniel Miller wrote:
>
>> Thanks for your feedback Sam.
>>
>> I agree. I will talk to the Struts developers about what I'm doing
>> before I
>> include their code into the Spring project.
>>
>> I was also leaning toward a tag library. Does anyone have input on
>> whether
>> another tag should be added to the Spring taglib or should it be a
>> totally
>> separate taglib (just for javascript validation)?
>>
>> Thanks.
>> Daniel
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]On 
>> Behalf
>> Of Sam Newman
>> Sent: Monday, March 08, 2004 5:42 AM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] Commons-Validator for Spring
>>
>>
>> Daniel Miller wrote:
>>> To all,
>>>
>>> I am looking into implementing the JavaScript portion of the
>>> Commons-Validator for Spring. I have a few questions on which I would
>>> appreciate some feedback:
>>>
>>> 1. Rather than re-invent the wheel I was planning on using as much
>> existing
>>> code as possible to implement JavaScript validation for Spring. It
>>> turns
>> out
>>> that the Struts source contains a lot of the code that "constructs"
>>> the
>>> JavaScript functions for the client. What are the policies for using
>>> code
>>> from other open-source projects in Spring? Can I just rip a bunch of
>>> code
>>> out of the Struts source and adapt it for Spring? Do I need to ask
>>> permission first?
>>
>> No matter what the license says, I think it would be advisable to ask 
>> -
>> some goodwill from the struts developers might well help the process.
>> In
>> fact the struts developers are known to be a big fan of their code
>> being
>> rebuilt as separate modules - the Jakarta commons projects started 
>> from
>> code in struts 1.0 being moved into separate projects. Struts is
>> licensed using the Apache license, as such their code can be used
>> without problem as long as correct attribution is given - this amounts
>> to stating in the code itself and the documentation where it came 
>> from.
>>
>>> 3. Would it be advisable to put the javascript generating code in the
>>> tag
>>> library or in the ValidatorFactory (which holds the resources needed
>>> to
>>> build the code; things like message resources would need to be passed
>>> in)?
>>
>> A tag library would be my preferred choice (I hate Java scriptlets in
>> JSP pages - a maintenance nightmare) although I suspect that the tag
>> would be a relatively thin wrapper over the ValidatorFactory itself.
>>
>> --
>> sam
>> http://www.magpiebrain.com/
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IBM Linux Tutorials
>> Free Linux tutorial presented by Daniel Robbins, President and CEO of
>> GenToo technologies. Learn everything from fundamentals to system
>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IBM Linux Tutorials
>> Free Linux tutorial presented by Daniel Robbins, President and CEO of
>> GenToo technologies. Learn everything from fundamentals to system
>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Commons-Validator for Spring

[Daniel M. <mi...@pa...>]

Matt,

The commons-validator adaptor for Spring is now in the sandbox on sf.net. I
would be happy to hear your comments/criticisms. The tag library is totally
separate, so you should be able to use this with any framework you please,
although it depends on a Spring BeanFactory to find the validator resources.
If there is a need, I suppose an alternative resource resolution strategy
could be implemented to remove this dependency.

The actual validation classes are fairly generic as well, so you shouldn't
even need to configure Spring to use them (although you will need the spring
jar with the Validator interface in it).

Thanks,
Daniel Miller

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Matt Raible
Sent: Thursday, March 11, 2004 11:36 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Commons-Validator for Spring


I've used the Struts Validator for a couple years now and I think it's
great - especially since I can generate my validation.xml using
XDoclet.  In the coming months, I plan to learn more about Tapestry and
WebWork.  I'd love to have a validation system that I could use on
Struts, Spring, Tapestry and WebWork.

I guess I'm saying - I'd like to see a tag library that can be used
with other MVC frameworks.  I plan on using Spring with all these MVC
options - so including it in the core also suits my needs.

Matt

On Mar 11, 2004, at 9:21 PM, Daniel Miller wrote:

> Thanks for your feedback Sam.
>
> I agree. I will talk to the Struts developers about what I'm doing
> before I
> include their code into the Spring project.
>
> I was also leaning toward a tag library. Does anyone have input on
> whether
> another tag should be added to the Spring taglib or should it be a
> totally
> separate taglib (just for javascript validation)?
>
> Thanks.
> Daniel
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Sam Newman
> Sent: Monday, March 08, 2004 5:42 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Commons-Validator for Spring
>
>
> Daniel Miller wrote:
>> To all,
>>
>> I am looking into implementing the JavaScript portion of the
>> Commons-Validator for Spring. I have a few questions on which I would
>> appreciate some feedback:
>>
>> 1. Rather than re-invent the wheel I was planning on using as much
> existing
>> code as possible to implement JavaScript validation for Spring. It
>> turns
> out
>> that the Struts source contains a lot of the code that "constructs"
>> the
>> JavaScript functions for the client. What are the policies for using
>> code
>> from other open-source projects in Spring? Can I just rip a bunch of
>> code
>> out of the Struts source and adapt it for Spring? Do I need to ask
>> permission first?
>
> No matter what the license says, I think it would be advisable to ask -
> some goodwill from the struts developers might well help the process.
> In
> fact the struts developers are known to be a big fan of their code
> being
> rebuilt as separate modules - the Jakarta commons projects started from
> code in struts 1.0 being moved into separate projects. Struts is
> licensed using the Apache license, as such their code can be used
> without problem as long as correct attribution is given - this amounts
> to stating in the code itself and the documentation where it came from.
>
>> 3. Would it be advisable to put the javascript generating code in the
>> tag
>> library or in the ValidatorFactory (which holds the resources needed
>> to
>> build the code; things like message resources would need to be passed
>> in)?
>
> A tag library would be my preferred choice (I hate Java scriptlets in
> JSP pages - a maintenance nightmare) although I suspect that the tag
> would be a relatively thin wrapper over the ValidatorFactory itself.
>
> --
> sam
> http://www.magpiebrain.com/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] commons validator adapter in sandbox

[Daniel M. <mi...@pa...>]

Message

 > Daniel - thanks a lot your contribution!  I made some *minor* code review
type polishing - be sure to test it to make sure I didn't break anything.
:-) Do you have unit tests developed you can contribute as well?

Thanks Keith. I'm glad to have my code edited. Unfortunately, I have not
developed any tests. I was hoping that someone could give me some pointers
on how to go about writing tests... I'm not very familiar with writing test
classes.

> I thought the code and design looked sharp.  Good docs, too.

Thanks. I'm humbled by your compliments.

> Here were a few things that I noticed on initial review:
>     - FieldChecks and JavascriptValidatorTag are a port over from the
commons-validator repository (FieldChecks is a particularly lengthy
copy-and-paste bit.)  Have you tried delegating to the "real" commons-owned
versions of these and adding in the spring adaption stuff via decoration?

I know, they were copied pretty much straight from Struts. Can you elaborate
on "the real commons-owned versions" please? I was not aware that
commons-validator v1.0.2 had these things (I know v1.1.1 does have some of
this, but it is considered alpha). I would be glad to use different code
here. In my opinion, it is the weakest point of my contribution. However, I
thought using the code that has been (at least) "weather tested" in Struts
would be better than rolling my own. What exactly do you mean by
"decoration"? Can you give an example?

>     - several setters must be called to set required
properties/dependencies post construction.  This is much less of an issue
when using the container, but when used programatically it's more difficult
to enforce that the object in a valid, usable state.  Fully-initializing
constructors make more sense to me in these cases (though I have to say I
appreciate you documenting those cases in the comments :-))

If you use the (undocumented--doh') constructors:

public ValidatorFactory(Resources[])
and
public BeanValidator(ValidatorFactory)

You need a ValidatorFactory to create a BeanValidator (or
NamedBeanValidator), but you shouldn't need to call any setter methods at
all if you use these constructors. I tried to provide options for both
setter and constructor setup, but maybe I overlooked something. Do enlighten
me if I have. I guess we need to modify the JavaDocs to document these.

>     - The use of "beanName", when referring to the "formName" (which
typically corresponds to the bean class being validating) confused me a bit
(since when I hear beanName I think of a reference to a instance, not a
class.)

I guess I didn't provide very good documentation of this naming convention.
I used this naming convention because future versions of the
Commons-Validator will use "bean" instead of "form" to refer to the object
being validated (or at least it's on the TODO list).

>     - The @TODO for per-request Locale support - could you expand upon
what you have in mind here? (do you have a need for working this in the near
future?)

I'm not sure what to do here--that's why it's a TODO. The commons-validator
can supposedly resolve validator definitions based on the locale of the
current request.  However, since the current Spring Validator interface does
not have a locale argument, I think we are out of luck here. I implemented
it the way it is because I don't like to worry about locale except in my
view (I thought that's what messages.properties are for anyway). To conclude
this ramble: I am open to suggestions.

> A few other questions I had:
I'd be happy to answer any others you happen to think of as well :-)

>     - How often do you use the NamedBeanValidator? When would you use it
(or in which cases is the BeanValidator that works with the class name not
good enough?

I do not see this as a highly-used class; it's just a bit more flexibility
for those extra special situations.
A NamedBeanValidator example is something that I need to add to the sample
app. I tried hard to explain it in the JavaDoc, but I guess I didn't do well
enough. I'll try again.

I envision people using NamedBeanValidator in two cases (there may be
others):

1. The class name of the bean being validated is not known or is the same
for multiple beans. In this case, the validator definition name can be
specified in the Spring configuration (but it is not mandatory, as it can be
specified at the time of validator invocation):
  <bean name="myBeanValidator" class="...NamedBeanValidator">
      ...
      <property name="beanName"><value>myBean</value></property>
      ...
  </bean>

  The following definition (in validation.xml) would validate this bean when
validate(command, errors) is invoked:

  <form name="myBean">
      ...
  </form>

  If no bean name was specified in the configuration, the validator
invocation would look like this:

  validate("myBean", command, errors);

  Note that this invocation is not Spring-automatic.

2. A single bean needs to be (partially?) validated by different definitions
at different times. For example, on a WizardFormController, the validate
method would invoke
  for page 1:
      validate("formPage1", command, errors)

  for page 2:
      validate("formPage2", command, errors)

  Each "formPageX" names a form definition in validation.xml that validates
the properties on that specific page. The final validation would simply
invoke each validate(...) method to ensure that all values entered during
the wizard flow are valid.
Hope that helped.

>     - Anything else you have planned or on the wishlist for declarative
validation?

At the current time it meets all my needs. I am waiting for response from
the community. I am sure there will be plenty of wishes when people start to
use this thing in the wild.
Did you have any ideas or is there anything you are wishing for?
Can you see a better way to do something that I have already done?

Thanks,
Daniel

Re: [Springframework-developer] RE: commons-validator adapter

[Baum, K. <Kar...@Ta...>]

It's great that Spring offers a developer so many options, but after a while
it may be difficult to separate core Spring from the convenient add ons.
What must a developer read up on before he or she understands what spring is
really about?  I would tend to side towards IOC, AOP, and the BeanFactory
before the commons validator plugin, but this does not mean a commons
validator plugin is not a great idea (I for one am trying to integrate it
into my current project.).  Each plugin that is integrated directly into the
project is yet another responsibility for the community of Spring developers
when it comes to documentation and maintenance.  This documentation, with
all of the add ons and plugins, will eventually become so bloated, the
average developer may become overwhelmed by it's size and complexity.

Why not farm these plugins out to smaller subprojects with teams of
developers focused on delivering a specific add on to the Spring project.
This leaves everyone with all of the great Spring options, but in the end
the Spring Framework never loses site of it's purpose  This isn't just about
the commons validator project.  With each new popular open source component,
we will need yet another package checked into the Spring project.  We can
start now with the spring-commons-validator subproject.

----- Original Message -----
From: "Brandon Goodin" <ma...@ph...>
To: <spr...@li...>
Sent: Monday, April 05, 2004 10:08 PM
Subject: RE: [Springframework-developer] RE: commons-validator adapter


> I understand that. I'm simply saying... leave the choices on other
websites
> and focus on what spring is. Not on all the neat toys you can plug into
it.
> So, where do you draw the line on what does and does not get included. Why
> not setup a directory of tools that can be used in spring instead of
feeling
> compelled to include support for every permutation into the distro or in
the
> spring cvs. Just cuz you can doesn't mean you should. I think moves like
> this will cause confusion around spring not help it.
>
> B
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
Of
> Seth Ladd
> Sent: Monday, April 05, 2004 5:29 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] RE: commons-validator adapter
>
> Brandon Goodin wrote:
> > commons validator? gack! Don't pollute spring with all of this crap. I
> > don't want to see spring turn into the 8000 pound gorilla that struts
> > has. Please consider making this stuff peripheral.
>
>
> A nice aspect of Spring is that it attempts to give developers different
> choices for a particular task.  For validation, commons-validator is
> just one choice.  Other choices include metadata validator or
> programmatic validation.  IMHO, the commons-validator fills a nice
> niche: when you want to do declarative validation but can't mark up the
> source code (if, for example, you're using generated source or 3rd party
> classes).
>
> With Spring, you get to Pick and Choose!
> Seth
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring IDE - Eclipse Plugin: Migration of SpringUI finished; Version 1.0.0 ready

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

>Does it make sense to host the plugin's update site
>and the corresponding HTML page on
>http://www.springframework.org/ or is SF.NET ok (the
>download of the Spring framework itself is hosted on
>SF.NET too)?
>
>  
>
Yes, I have copied the files to -
http://www.springframework.org/spring-ide/eclipse/

Do we want to keep the updatesite on sourceforge?

Thomas

RE: [Springframework-developer] RE: commons-validator adapter

[Brandon G. <ma...@ph...>]

I understand that. I'm simply saying... leave the choices on other websites
and focus on what spring is. Not on all the neat toys you can plug into it.
So, where do you draw the line on what does and does not get included. Why
not setup a directory of tools that can be used in spring instead of feeling
compelled to include support for every permutation into the distro or in the
spring cvs. Just cuz you can doesn't mean you should. I think moves like
this will cause confusion around spring not help it.

B

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Seth Ladd
Sent: Monday, April 05, 2004 5:29 PM
To: spr...@li...
Subject: Re: [Springframework-developer] RE: commons-validator adapter

Brandon Goodin wrote:
> commons validator? gack! Don't pollute spring with all of this crap. I 
> don't want to see spring turn into the 8000 pound gorilla that struts 
> has. Please consider making this stuff peripheral.


A nice aspect of Spring is that it attempts to give developers different 
choices for a particular task.  For validation, commons-validator is 
just one choice.  Other choices include metadata validator or 
programmatic validation.  IMHO, the commons-validator fills a nice 
niche: when you want to do declarative validation but can't mark up the 
source code (if, for example, you're using generated source or 3rd party 
classes).

With Spring, you get to Pick and Choose!
Seth


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] RE: commons-validator adapter

[Seth L. <se...@eh...>]

Brandon Goodin wrote:
> commons validator? gack! Don't pollute spring with all of this crap. I 
> don't want to see spring turn into the 8000 pound gorilla that struts 
> has. Please consider making this stuff peripheral.


A nice aspect of Spring is that it attempts to give developers different 
choices for a particular task.  For validation, commons-validator is 
just one choice.  Other choices include metadata validator or 
programmatic validation.  IMHO, the commons-validator fills a nice 
niche: when you want to do declarative validation but can't mark up the 
source code (if, for example, you're using generated source or 3rd party 
classes).

With Spring, you get to Pick and Choose!
Seth

[Springframework-developer] RE: commons-validator adapter

[Brandon G. <Bra...@pl...>]

commons validator? gack! Don't pollute spring with all of this crap. I
don't want to see spring turn into the 8000 pound gorilla that struts
has. Please consider making this stuff peripheral.

>>> kd...@cs... 4/5/2004 4:58:47 PM >>>
Daniel,
 
I put the spring-commons-validator.tld file in the sandbox at:
 
    src/sandbox/org/springframework/web/servlet/tags
 
I've initially set the optional short name as
"Spring-Commons-Validator" and the optional URI as
http://www.springframework.org/tags/commons-validator
 
Keith
 
-----Original Message-----
From: Daniel Miller [mailto:mi...@pa...] 
Sent: Friday, April 02, 2004 6:51 PM
To: Keith Donald
Subject: RE: commons-validator adapter

Keith,
 
This just in from Karl Baum, who is using the same source that you
recently downloaded from my web space:
 
        ...the uri and shorname element element in
spring-commonsvalidator.tld are:
 
    <shortname>html</shortname>
    <uri>http://jakarta.apache.org/struts/tags-html</uri>
 
Unless you know of any conflicts, I suggest that we set the shortname
to "scv" for "Spring Commons-Validator".
I guess the uri should be http://www.springframework.org/scv unless you
have a better idea.
 
You can go ahead and make these changes before you put the code in the
sandbox if you want.
 
Thanks,
Daniel

[Springframework-developer] RE: commons-validator adapter

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

Daniel,
=20
I put the spring-commons-validator.tld file in the sandbox at:
=20
    src/sandbox/org/springframework/web/servlet/tags
=20
I've initially set the optional short name as "Spring-Commons-Validator" =
and
the optional URI as =
http://www.springframework.org/tags/commons-validator
=20
Keith
=20
-----Original Message-----
From: Daniel Miller [mailto:mi...@pa...]=20
Sent: Friday, April 02, 2004 6:51 PM
To: Keith Donald
Subject: RE: commons-validator adapter


Keith,
=20
This just in from Karl Baum, who is using the same source that you =
recently
downloaded from my web space:
=20
        ...the uri and shorname element element in
spring-commonsvalidator.tld are:
=20
    <shortname>html</shortname>
    <uri>http://jakarta.apache.org/struts/tags-html</uri>
=20
Unless you know of any conflicts, I suggest that we set the shortname to
"scv" for "Spring Commons-Validator".
I guess the uri should be  <http://www.springframework.org/scv>
http://www.springframework.org/scv unless you have a better idea.
=20
You can go ahead and make these changes before you put the code in the
sandbox if you want.
=20
Thanks,
Daniel