springframework-developer

[Springframework-developer] Where does webflow live?

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

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

Thanks,

Matt

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

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

Well, Web Flow currently lives in our sandbox, so spring-sandbox.jar
essentially contains Web Flow in its entirety.

On the occasion: We should move the Commons Validator support to some proper
place. Rob, wouldn't that be a further candidate for Spring Modules?

Juergen


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


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

Thanks,

Matt



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

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

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

That's not a bad idea. Once we have the 0.1 release out I'll move this stuff
across and we'll try to include it in 0.2 or 0.3.

Rob

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

Well, Web Flow currently lives in our sandbox, so spring-sandbox.jar
essentially contains Web Flow in its entirety.

On the occasion: We should move the Commons Validator support to some proper
place. Rob, wouldn't that be a further candidate for Spring Modules?

Juergen


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


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

Thanks,

Matt



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



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

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

[Keith D. <ke...@in...>]

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

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

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

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

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

Keith




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

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

Thanks,

Matt



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

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

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

Ah, our favorite topic once again ;-)

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

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

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

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

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

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

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

Juergen


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


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

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

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

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

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

Keith




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

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

Thanks,

Matt



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



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

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

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

Wow, that came in late... that's a rant from last night, actually ;-)

Juergen


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


Ah, our favorite topic once again ;-)

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

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

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

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

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

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

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

Juergen


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


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

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

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

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

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

Keith




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

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

Thanks,

Matt



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



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



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

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

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

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

Rob

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

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

Ah, our favorite topic once again ;-)

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

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

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

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

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

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

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

Juergen


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


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

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

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

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

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

Keith




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

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

Thanks,

Matt



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



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



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

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

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

Rob,

So what is the plan for the springmodules - is this going to be one 
monolithic collection of modules or do you plan to split it up into 
specific subprojects?  I have a couple of small modules that could live 
there but I'm not sure of how to coordinate adding them and creating a 
distributable jar file.  Do you see each module as an independent piece 
that will have its own jar file or do you envision a single 
springmodules.jar?

Thomas

On Apr 13, 2005, at 7:34 AM, Rob Harrop wrote:

> Well, I'll spend some time going through the sandbox and see what I 
> think is
> a candidate for Spring Modules. I'll post the suggestions here and if
> everyone is happy I'll do the move. We have about 6 active developers 
> on SM
> who are not core Spring devs, plus there is me so we may be able to 
> breath
> some live back into the stuff in the sandbox.
>
> Rob
>
> --
> Rob Harrop
> Interface21 - Spring Services from the Source
> http://www.springframework.com
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of
> Juergen Hoeller
> Sent: 12 April 2005 22:17
> To: spr...@li...
> Subject: Re: [Springframework-developer] Where does webflow live?
>
> Ah, our favorite topic once again ;-)
>
> I'm not entirely sure whether Web Flow will get its own module; could 
> be too
> fine-granular. The binding framework quite certainly shouldn't, which 
> would
> already cause a problem with Web Flow's current status if we had 
> modules.
>
> To give some numbers: If we want to have the binding framework, JCA 
> support,
> Hibernate support, Web Flow, etc as separate modules (which would be
> necessary to get your desired effect of not putting any early-access 
> stuff
> in the sandbox), we would end up with at least 35 modules (that's our
> top-level packages plus some subpackages of relevant size). Frankly, I
> consider that a horror scenario in terms of management and would 
> strongly
> vote against it.
>
> I guess what I'm saying is that modules only *look* convincingly easy, 
> but
> won't be a general solution for the early access problem in practice. 
> Keith,
> please try to imagine this in detail and don't just consider it as 
> solution
> upfront. This is absolutely non-trivial when looking at the details.
>
> Before we continue to spread the word on modules, I'd like to see 
> concrete
> suggestions for module separation, respecting the interdependencies 
> outlined
> in section 3 of our readme. I have already tried multiple times to 
> nail down
> some options, and have always failed to find a convincing separation.
>
> The current jar files (12) might be a starting point, but I'm not sure 
> that
> they can serve as module granularity too... Some packages are joined
> together there rather arbitrarily (from a source module perspective), 
> for
> example the ones in spring-support.jar, or the separation between
> spring-orm.jar (which includes the entire ORM support except for 
> Hibernate)
> and spring-hibernate.jar. Those jar files cannot be mapped 1-to-1 to 
> source
> modules.
>
> So in total, it's unclear to me how a concrete module separation could 
> look
> like (the more I look at it, the harder it seems). I doubt that we can
> resolve this within the 1.3 timeframe, given that we have such an 
> aggressive
> schedule there, with just two months for multiple major new features.
>
> Anyway, the real problem here is the sandbox, IMO. There's too much 
> stuff in
> there, both dead and somewhat alive. Noone should have to rely on
> spring-sandbox.jar!! Everything that's of some use in there should 
> move,
> either to the core or to Spring Modules.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Keith Donald
> Sent: Tuesday, April 12, 2005 9:24 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Where does webflow live?
>
>
> Aye, this is exactly why we need a modular CVS structure and a smarter
> build, which Colin is leading up in the post 1.2 timeframe.
>
> Web flow is currently maintained in the sandbox, yes.  This means it 
> is also
> included in spring-sandbox.jar when the 'sandboxjar' target is run.
>
> Independent of that fact, the webflow.release target ships
> spring-webflow.jar and spring-webflow-support.jar, pulling in _just_ 
> the
> required code from the sandbox needed to run spring webflow.
>
> So, I guess you can say we've taken the stance that people aren't 
> developing
> apps with spring-sandbox.jar in their classpath.  Hmm...
>
> In any case, in the future spring-webflow will be in its own module 
> with its
> own distributable, along side other well-defined core modules, and the
> sandbox will die the death it deserves (or be only used for true 
> 'scratch'
> stuff)
>
> Keith
>
>
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of
> Matt Raible
> Sent: Tuesday, April 12, 2005 3:04 PM
> To: spr...@li...
> Subject: [Springframework-developer] Where does webflow live?
>
> I ran into some issues last night with spring-sandbox.jar from Spring
> 1.2 RC1 and Spring Web Flow PR2.  The problem turned out to be that
> many of the flow classes where already in my spring-sandbox.jar.  Once
> I deleted them from spring-sandbox.jar, everything worked fine.  How do
> I eliminate this duplication in the future?  Is the web flow stuff in
> spring-sandbox.jar?  The main reason I'm using the sandbox JAR is for
> Commons Validator.
>
> Thanks,
>
> Matt
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

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

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

Thomas Risberg wrote:

> Rob,
>
> So what is the plan for the springmodules - is this going to be one 
> monolithic collection of modules or do you plan to split it up into 
> specific subprojects?  I have a couple of small modules that could 
> live there but I'm not sure of how to coordinate adding them and 
> creating a distributable jar file.  Do you see each module as an 
> independent piece that will have its own jar file or do you envision a 
> single springmodules.jar?
>
I guess that springmodules.jar would be too coarse grained. I would lean 
towards a separate jar per module. What do others think?

Dmitriy.

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

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

Both approaches have advantages. If the overall size is rather small, I
would lean towards a single springmodules.jar. If it starts getting bigger,
offer both a full springmodules.jar and some finer-grained jar files (but
not necessarily one for each piece of code, rather one for each high-level
package). This is essentially what we're doing in core Spring too.

The other question is how to organize the springmodules source tree. As I've
already argued, jar file separation does not have to match source tree
separation. A single source tree can be used to generate multiple jar files,
just like we currently do for core Spring.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Dmitriy Kopylenko
Sent: Wednesday, April 13, 2005 2:29 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Where does webflow live?


Thomas Risberg wrote:

> Rob,
>
> So what is the plan for the springmodules - is this going to be one
> monolithic collection of modules or do you plan to split it up into
> specific subprojects?  I have a couple of small modules that could
> live there but I'm not sure of how to coordinate adding them and
> creating a distributable jar file.  Do you see each module as an
> independent piece that will have its own jar file or do you envision a
> single springmodules.jar?
>
I guess that springmodules.jar would be too coarse grained. I would lean
towards a separate jar per module. What do others think?

Dmitriy.


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

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

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

Rob,

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

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

Thomas


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

> Well, I'll spend some time going through the sandbox and see what I think is
> a candidate for Spring Modules. I'll post the suggestions here and if
> everyone is happy I'll do the move. We have about 6 active developers on SM
> who are not core Spring devs, plus there is me so we may be able to breath
> some live back into the stuff in the sandbox.
>
> Rob
>
> --
> Rob Harrop
> Interface21 - Spring Services from the Source
> http://www.springframework.com
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf Of
> Juergen Hoeller
> Sent: 12 April 2005 22:17
> To: spr...@li...
> Subject: Re: [Springframework-developer] Where does webflow live?
>
> Ah, our favorite topic once again ;-)
>
> I'm not entirely sure whether Web Flow will get its own module; could be too
> fine-granular. The binding framework quite certainly shouldn't, which would
> already cause a problem with Web Flow's current status if we had modules.
>
> To give some numbers: If we want to have the binding framework, JCA support,
> Hibernate support, Web Flow, etc as separate modules (which would be
> necessary to get your desired effect of not putting any early-access stuff
> in the sandbox), we would end up with at least 35 modules (that's our
> top-level packages plus some subpackages of relevant size). Frankly, I
> consider that a horror scenario in terms of management and would strongly
> vote against it.
>
> I guess what I'm saying is that modules only *look* convincingly easy, but
> won't be a general solution for the early access problem in practice. Keith,
> please try to imagine this in detail and don't just consider it as solution
> upfront. This is absolutely non-trivial when looking at the details.
>
> Before we continue to spread the word on modules, I'd like to see concrete
> suggestions for module separation, respecting the interdependencies outlined
> in section 3 of our readme. I have already tried multiple times to nail down
> some options, and have always failed to find a convincing separation.
>
> The current jar files (12) might be a starting point, but I'm not sure that
> they can serve as module granularity too... Some packages are joined
> together there rather arbitrarily (from a source module perspective), for
> example the ones in spring-support.jar, or the separation between
> spring-orm.jar (which includes the entire ORM support except for Hibernate)
> and spring-hibernate.jar. Those jar files cannot be mapped 1-to-1 to source
> modules.
>
> So in total, it's unclear to me how a concrete module separation could look
> like (the more I look at it, the harder it seems). I doubt that we can
> resolve this within the 1.3 timeframe, given that we have such an aggressive
> schedule there, with just two months for multiple major new features.
>
> Anyway, the real problem here is the sandbox, IMO. There's too much stuff in
> there, both dead and somewhat alive. Noone should have to rely on
> spring-sandbox.jar!! Everything that's of some use in there should move,
> either to the core or to Spring Modules.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Keith Donald
> Sent: Tuesday, April 12, 2005 9:24 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Where does webflow live?
>
>
> Aye, this is exactly why we need a modular CVS structure and a smarter
> build, which Colin is leading up in the post 1.2 timeframe.
>
> Web flow is currently maintained in the sandbox, yes.  This means it is also
> included in spring-sandbox.jar when the 'sandboxjar' target is run.
>
> Independent of that fact, the webflow.release target ships
> spring-webflow.jar and spring-webflow-support.jar, pulling in _just_ the
> required code from the sandbox needed to run spring webflow.
>
> So, I guess you can say we've taken the stance that people aren't developing
> apps with spring-sandbox.jar in their classpath.  Hmm...
>
> In any case, in the future spring-webflow will be in its own module with its
> own distributable, along side other well-defined core modules, and the
> sandbox will die the death it deserves (or be only used for true 'scratch'
> stuff)
>
> Keith
>
>
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf Of
> Matt Raible
> Sent: Tuesday, April 12, 2005 3:04 PM
> To: spr...@li...
> Subject: [Springframework-developer] Where does webflow live?
>
> I ran into some issues last night with spring-sandbox.jar from Spring
> 1.2 RC1 and Spring Web Flow PR2.  The problem turned out to be that
> many of the flow classes where already in my spring-sandbox.jar.  Once
> I deleted them from spring-sandbox.jar, everything worked fine.  How do
> I eliminate this duplication in the future?  Is the web flow stuff in
> spring-sandbox.jar?  The main reason I'm using the sandbox JAR is for
> Commons Validator.
>
> Thanks,
>
> Matt
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

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

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

Thomas,

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

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

> Rob,
>
> I'm currently working on a project where I will use Commons Validator 
> outside of
> a Web MVC environment.  I still would like to be able to wire it up 
> using Spring
> and I have been playing around with what's in the sandbox.  I have 
> already
> changed the package names, so let me know when/if it is a good time to 
> move
> this to springmodules CVS.
>
> I moved most of it to org.springmodules.validation.commons package 
> except for
> the tag library which I put in
> org.springmodules.web.servlet.tags.validation.commons.  I guess it 
> makes sense
> to keep the package structure in org.springmodules the same as
> org.springframework so it's easier to move code between the projects.
>
> Thomas
>
>
> Quoting Rob Harrop <rob...@in...>:
>
>> Well, I'll spend some time going through the sandbox and see what I 
>> think is
>> a candidate for Spring Modules. I'll post the suggestions here and if
>> everyone is happy I'll do the move. We have about 6 active developers 
>> on SM
>> who are not core Spring devs, plus there is me so we may be able to 
>> breath
>> some live back into the stuff in the sandbox.
>>
>> Rob
>>
>> --
>> Rob Harrop
>> Interface21 - Spring Services from the Source
>> http://www.springframework.com
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On 
>> Behalf Of
>> Juergen Hoeller
>> Sent: 12 April 2005 22:17
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] Where does webflow live?
>>
>> Ah, our favorite topic once again ;-)
>>
>> I'm not entirely sure whether Web Flow will get its own module; could 
>> be too
>> fine-granular. The binding framework quite certainly shouldn't, which 
>> would
>> already cause a problem with Web Flow's current status if we had 
>> modules.
>>
>> To give some numbers: If we want to have the binding framework, JCA 
>> support,
>> Hibernate support, Web Flow, etc as separate modules (which would be
>> necessary to get your desired effect of not putting any early-access 
>> stuff
>> in the sandbox), we would end up with at least 35 modules (that's our
>> top-level packages plus some subpackages of relevant size). Frankly, I
>> consider that a horror scenario in terms of management and would 
>> strongly
>> vote against it.
>>
>> I guess what I'm saying is that modules only *look* convincingly 
>> easy, but
>> won't be a general solution for the early access problem in practice. 
>> Keith,
>> please try to imagine this in detail and don't just consider it as 
>> solution
>> upfront. This is absolutely non-trivial when looking at the details.
>>
>> Before we continue to spread the word on modules, I'd like to see 
>> concrete
>> suggestions for module separation, respecting the interdependencies 
>> outlined
>> in section 3 of our readme. I have already tried multiple times to 
>> nail down
>> some options, and have always failed to find a convincing separation.
>>
>> The current jar files (12) might be a starting point, but I'm not 
>> sure that
>> they can serve as module granularity too... Some packages are joined
>> together there rather arbitrarily (from a source module perspective), 
>> for
>> example the ones in spring-support.jar, or the separation between
>> spring-orm.jar (which includes the entire ORM support except for 
>> Hibernate)
>> and spring-hibernate.jar. Those jar files cannot be mapped 1-to-1 to 
>> source
>> modules.
>>
>> So in total, it's unclear to me how a concrete module separation 
>> could look
>> like (the more I look at it, the harder it seems). I doubt that we can
>> resolve this within the 1.3 timeframe, given that we have such an 
>> aggressive
>> schedule there, with just two months for multiple major new features.
>>
>> Anyway, the real problem here is the sandbox, IMO. There's too much 
>> stuff in
>> there, both dead and somewhat alive. Noone should have to rely on
>> spring-sandbox.jar!! Everything that's of some use in there should 
>> move,
>> either to the core or to Spring Modules.
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]On 
>> Behalf
>> Of Keith Donald
>> Sent: Tuesday, April 12, 2005 9:24 PM
>> To: spr...@li...
>> Subject: RE: [Springframework-developer] Where does webflow live?
>>
>>
>> Aye, this is exactly why we need a modular CVS structure and a smarter
>> build, which Colin is leading up in the post 1.2 timeframe.
>>
>> Web flow is currently maintained in the sandbox, yes.  This means it 
>> is also
>> included in spring-sandbox.jar when the 'sandboxjar' target is run.
>>
>> Independent of that fact, the webflow.release target ships
>> spring-webflow.jar and spring-webflow-support.jar, pulling in _just_ 
>> the
>> required code from the sandbox needed to run spring webflow.
>>
>> So, I guess you can say we've taken the stance that people aren't 
>> developing
>> apps with spring-sandbox.jar in their classpath.  Hmm...
>>
>> In any case, in the future spring-webflow will be in its own module 
>> with its
>> own distributable, along side other well-defined core modules, and the
>> sandbox will die the death it deserves (or be only used for true 
>> 'scratch'
>> stuff)
>>
>> Keith
>>
>>
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On 
>> Behalf Of
>> Matt Raible
>> Sent: Tuesday, April 12, 2005 3:04 PM
>> To: spr...@li...
>> Subject: [Springframework-developer] Where does webflow live?
>>
>> I ran into some issues last night with spring-sandbox.jar from Spring
>> 1.2 RC1 and Spring Web Flow PR2.  The problem turned out to be that
>> many of the flow classes where already in my spring-sandbox.jar.  Once
>> I deleted them from spring-sandbox.jar, everything worked fine.  How 
>> do
>> I eliminate this duplication in the future?  Is the web flow stuff in
>> spring-sandbox.jar?  The main reason I'm using the sandbox JAR is for
>> Commons Validator.
>>
>> Thanks,
>>
>> Matt
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real 
>> users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real 
>> users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real 
>> users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real 
>> users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
-- 
Rob Harrop
Interface21 - Spring Services from the Source
http://www.springframework.com

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

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

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

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


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

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

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

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

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

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

Thomas


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

> Thomas,
>
> If you are willing to work on it, I am happy for you to move it to  
> Spring Modules now. I don't see any harm in including what is there in  
> a 0.1 release if you are happy with it.
>
> Rob
> On 13 Apr 2005, at 20:52, tho...@tr... wrote:
>
>> Rob,
>>
>> I'm currently working on a project where I will use Commons Validator  
>> outside of
>> a Web MVC environment.  I still would like to be able to wire it up  
>> using Spring
>> and I have been playing around with what's in the sandbox.  I have  
>> already
>> changed the package names, so let me know when/if it is a good time  
>> to move
>> this to springmodules CVS.
>>
>> I moved most of it to org.springmodules.validation.commons package  
>> except for
>> the tag library which I put in
>> org.springmodules.web.servlet.tags.validation.commons.  I guess it  
>> makes sense
>> to keep the package structure in org.springmodules the same as
>> org.springframework so it's easier to move code between the projects.
>>
>> Thomas
>>
>>
>> Quoting Rob Harrop <rob...@in...>:
>>
>>> Well, I'll spend some time going through the sandbox and see what I  
>>> think is
>>> a candidate for Spring Modules. I'll post the suggestions here and if
>>> everyone is happy I'll do the move. We have about 6 active  
>>> developers on SM
>>> who are not core Spring devs, plus there is me so we may be able to  
>>> breath
>>> some live back into the stuff in the sandbox.
>>>
>>> Rob
>>>
>>> --
>>> Rob Harrop
>>> Interface21 - Spring Services from the Source
>>> http://www.springframework.com
>>>
>>> -----Original Message-----
>>> From: spr...@li...
>>> [mailto:spr...@li...] On  
>>> Behalf Of
>>> Juergen Hoeller
>>> Sent: 12 April 2005 22:17
>>> To: spr...@li...
>>> Subject: Re: [Springframework-developer] Where does webflow live?
>>>
>>> Ah, our favorite topic once again ;-)
>>>
>>> I'm not entirely sure whether Web Flow will get its own module;  
>>> could be too
>>> fine-granular. The binding framework quite certainly shouldn't,  
>>> which would
>>> already cause a problem with Web Flow's current status if we had  
>>> modules.
>>>
>>> To give some numbers: If we want to have the binding framework, JCA  
>>> support,
>>> Hibernate support, Web Flow, etc as separate modules (which would be
>>> necessary to get your desired effect of not putting any early-access  
>>> stuff
>>> in the sandbox), we would end up with at least 35 modules (that's our
>>> top-level packages plus some subpackages of relevant size). Frankly,  
>>> I
>>> consider that a horror scenario in terms of management and would  
>>> strongly
>>> vote against it.
>>>
>>> I guess what I'm saying is that modules only *look* convincingly  
>>> easy, but
>>> won't be a general solution for the early access problem in  
>>> practice. Keith,
>>> please try to imagine this in detail and don't just consider it as  
>>> solution
>>> upfront. This is absolutely non-trivial when looking at the details.
>>>
>>> Before we continue to spread the word on modules, I'd like to see  
>>> concrete
>>> suggestions for module separation, respecting the interdependencies  
>>> outlined
>>> in section 3 of our readme. I have already tried multiple times to  
>>> nail down
>>> some options, and have always failed to find a convincing separation.
>>>
>>> The current jar files (12) might be a starting point, but I'm not  
>>> sure that
>>> they can serve as module granularity too... Some packages are joined
>>> together there rather arbitrarily (from a source module  
>>> perspective), for
>>> example the ones in spring-support.jar, or the separation between
>>> spring-orm.jar (which includes the entire ORM support except for  
>>> Hibernate)
>>> and spring-hibernate.jar. Those jar files cannot be mapped 1-to-1 to  
>>> source
>>> modules.
>>>
>>> So in total, it's unclear to me how a concrete module separation  
>>> could look
>>> like (the more I look at it, the harder it seems). I doubt that we  
>>> can
>>> resolve this within the 1.3 timeframe, given that we have such an  
>>> aggressive
>>> schedule there, with just two months for multiple major new features.
>>>
>>> Anyway, the real problem here is the sandbox, IMO. There's too much  
>>> stuff in
>>> there, both dead and somewhat alive. Noone should have to rely on
>>> spring-sandbox.jar!! Everything that's of some use in there should  
>>> move,
>>> either to the core or to Spring Modules.
>>>
>>> Juergen
>>>
>>>
>>> -----Original Message-----
>>> From: spr...@li...
>>> [mailto:spr...@li...]On  
>>> Behalf
>>> Of Keith Donald
>>> Sent: Tuesday, April 12, 2005 9:24 PM
>>> To: spr...@li...
>>> Subject: RE: [Springframework-developer] Where does webflow live?
>>>
>>>
>>> Aye, this is exactly why we need a modular CVS structure and a  
>>> smarter
>>> build, which Colin is leading up in the post 1.2 timeframe.
>>>
>>> Web flow is currently maintained in the sandbox, yes.  This means it  
>>> is also
>>> included in spring-sandbox.jar when the 'sandboxjar' target is run.
>>>
>>> Independent of that fact, the webflow.release target ships
>>> spring-webflow.jar and spring-webflow-support.jar, pulling in _just_  
>>> the
>>> required code from the sandbox needed to run spring webflow.
>>>
>>> So, I guess you can say we've taken the stance that people aren't  
>>> developing
>>> apps with spring-sandbox.jar in their classpath.  Hmm...
>>>
>>> In any case, in the future spring-webflow will be in its own module  
>>> with its
>>> own distributable, along side other well-defined core modules, and  
>>> the
>>> sandbox will die the death it deserves (or be only used for true  
>>> 'scratch'
>>> stuff)
>>>
>>> Keith
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: spr...@li...
>>> [mailto:spr...@li...] On  
>>> Behalf Of
>>> Matt Raible
>>> Sent: Tuesday, April 12, 2005 3:04 PM
>>> To: spr...@li...
>>> Subject: [Springframework-developer] Where does webflow live?
>>>
>>> I ran into some issues last night with spring-sandbox.jar from Spring
>>> 1.2 RC1 and Spring Web Flow PR2.  The problem turned out to be that
>>> many of the flow classes where already in my spring-sandbox.jar.   
>>> Once
>>> I deleted them from spring-sandbox.jar, everything worked fine.  How  
>>> do
>>> I eliminate this duplication in the future?  Is the web flow stuff in
>>> spring-sandbox.jar?  The main reason I'm using the sandbox JAR is for
>>> Commons Validator.
>>>
>>> Thanks,
>>>
>>> Matt
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF email is sponsored by - The IT Product Guide
>>> Read honest & candid reviews on hundreds of IT Products from real  
>>> users.
>>> Discover which products truly live up to the hype. Start reading now.
>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>>> developer
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF email is sponsored by - The IT Product Guide
>>> Read honest & candid reviews on hundreds of IT Products from real  
>>> users.
>>> Discover which products truly live up to the hype. Start reading now.
>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>>> developer
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF email is sponsored by - The IT Product Guide
>>> Read honest & candid reviews on hundreds of IT Products from real  
>>> users.
>>> Discover which products truly live up to the hype. Start reading now.
>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>>> developer
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF email is sponsored by - The IT Product Guide
>>> Read honest & candid reviews on hundreds of IT Products from real  
>>> users.
>>> Discover which products truly live up to the hype. Start reading now.
>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>>> developer
>>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real  
>> users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
> -- 
> Rob Harrop
> Interface21 - Spring Services from the Source
> http://www.springframework.com
>
> Lead Developer - AOP & JMX, Spring Framework:
> http://www.springframework.org
>
> Author, "Pro Spring"
> (February 2005, with Jan Machacek).
> http://www.amazon.com/exec/obidos/ASIN/1590594614/
>
> Author, "Pro Jakarta Velocity"
> (August 2004).
> http://www.amazon.com/exec/obidos/ASIN/159059410X/
>
> Author, "Pro Jakarta Struts"
> (March 2004, with John Carnell).
> http://www.amazon.com/exec/obidos/ASIN/159059228X/
>
>
> ____________________________________________________
> Interface21 Limited
> Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent  
> DA1 2JY
> Registered in England and Wales No. 5187766
> ____________________________________________________
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real  
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

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

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

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

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

This results in the following error:

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

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

Thanks,

Matt

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

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

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

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

Matt,

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

Thanks for testing it :)

Thomas


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

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

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

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

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

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

Matt


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

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

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

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

Matt,

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

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

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

Thomas


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

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

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

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

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

Matt

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

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

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

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

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

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

Thanks,

Matt

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

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

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

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

Matt,

 

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

 

Rob

 

  _____  

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

 

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

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

Thanks,

Matt

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

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

Matt

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

Matt,

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

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






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

Thomas


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

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

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

Matt


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

Matt,

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

Thanks for testing it :)

Thomas


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

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

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

This results in the following error:

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

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

Thanks,

Matt

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

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

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

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

Thomas


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

Thomas,

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

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

Rob,

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

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

Thomas


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

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

Rob

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

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

Ah, our favorite topic once again ;-)

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

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

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

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

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

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

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

Juergen


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


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

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

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

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

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

Keith




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

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

Thanks,

Matt



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



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



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



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






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

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

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

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

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

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


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




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






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




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






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




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

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

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

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

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

> when you get a chance to us it.

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

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

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

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

plan on making before the 0.1 release?

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

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

it out results in:

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

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

tTag(JavascriptValidatorTag.java:334)

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

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

Matt

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

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

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

> JAR?
>
>  Thanks,
>
>  Matt
>

Re: [Springframework-developer] Commons Validator

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

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

Rob

Matt Raible wrote:

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

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

[Keith D. <ke...@in...>]

I don't see why Web Flow should not be its own module.  It's 135K as is,
probably around 115 classes.  I also think data binding could nicely be its
own module as well, upon which web flow would depend.  A smart build system
would make things manageable.

Look at how the eclipse project does it -- they have lots of different
modules for the different parts of Eclipse, and they're successful at it.
I'm not saying Hibernate and OJB and iBatis should each be their own, for
example, that's probably a bit xtreme -- but ORM might well be.

We probably shouldn't get distracted by this now given 1.2.

Keith

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

Ah, our favorite topic once again ;-)

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

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

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

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

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

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

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

Juergen


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


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

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

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

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

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

Keith




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

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

Thanks,

Matt



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



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



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

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

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

Well, in general, I wouldn't mind Web Flow getting its own module, for
example following our current jar file structure (where spring-webflow.jar
will be the 13th jar file). However, as I said, I'm not sure our jar files
really provide a good basis for a source module structure... they are
separated by jar size / deployment combo rules, not necessarily by logical
modules.

Data binding is quite definitely too small for a module. If we give data
binding its own module, we'll consequently *have* to give JNDI support, JMS
support, JCA support, Hibernate support, etc all their own modules as well -
and then we'll end up with ~35 modules. There is no point in giving data
binding a special status here, IMO...

A smart build system is also able to generate all sorts of deployables from
a *single* source tree, without separation into multiple separate source
trees. Even subpackage interdependencies could be checked through selective
compilation. The advantage would be that we can keep refining the
granularity of the deployables, like we can do now. With multiple source
trees, we'd have to move packages between source directories for this, and
thus lose our version history etc.

I'm not saying that we shouldn't go down the module route in general. I'm
just saying that it's too early to promise anything in that area, as the
final word has not been spoken yet, not even on *whether* we go down the
module route within our now very aggressive 1.3 schedule. Before we continue
to assume anything here, I'd like to see a concrete proposal for module
separation,  taking our entire codebase into account in a detailed and
balanced fashion, not just reiterating that modules for data binding and web
flow would be nice.

I guess I'm just sick of the argument that we wouldn't have a problem with
Web Flow's (or other sandbox stuff's) current residence if we had source
modules. That's simply not true if you look at it a bit closer: There will
always be extensions that have to go into an existing module - and have to
reside in some sort of sandbox until they get moved over to the main
sources.

Juergen


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


I don't see why Web Flow should not be its own module.  It's 135K as is,
probably around 115 classes.  I also think data binding could nicely be its
own module as well, upon which web flow would depend.  A smart build system
would make things manageable.

Look at how the eclipse project does it -- they have lots of different
modules for the different parts of Eclipse, and they're successful at it.
I'm not saying Hibernate and OJB and iBatis should each be their own, for
example, that's probably a bit xtreme -- but ORM might well be.

We probably shouldn't get distracted by this now given 1.2.

Keith

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

Ah, our favorite topic once again ;-)

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

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

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

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

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

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

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

Juergen


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


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

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

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

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

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

Keith




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

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

Thanks,

Matt



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



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



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



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