springframework-developer — Spring Framework developers list

Re: [Springframework-user] Re: [Springframework-developer] New www.springframework.org site is live!

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

On May 5, 2005, at 2:45 PM, Colin Sampaleanu wrote:

> The CMS here is Drupal.
>
> It's certainly possible to handle historical URLs, and some already  
> are. Most of the site is handled dynamically by Drupal, but
>   /dtd
> and
>  /buttons
> is redirected internally (invisibly) by Apache to the new
>  http://static.springframework.org
> site meant for completely static content like online documentation. It  
> was critical to do this to not break DTD URLs and existing button  
> links using the images directly from the Spring website.
>
> There is a question of what to do this for however. The old static  
> structure was somewhat adhoc and simplistic. If you look at your  
> example
>    
> http://www.springframework.org/docs/api/org/springframework/web/ 
> servlet/mvc/SimpleFormController.html
> there's no product name (spring base library vs. webflow vs whatever  
> other lib) in there, and there's no version number. Under the new  
> structure, this is available as
>   
> http://static.springframework.org/spring/docs/1.1.5/api/org/ 
> springframework/web/servlet/mvc/SimpleFormController.html

I can see your point.  However, in Spring Live - whenever I've  
mentioned a class name, I've linked to it's javadoc - making it easy  
for readers to look up and see more information about a class.  I did  
this on a couple while writing and the tech editors and readers liked  
it so much, I did it for all of them.  I'd hate to have to go back  
through and change all these links to point to a specific product and  
version number.

Matt

>
> Colin
>
> Matt Raible wrote:
>
>> Nice work guys - now we just need to get you to write the CMS using   
>> Spring. ;-)  I'm guessing this site uses Plone like the   
>> springframework.com site?
>>
>> One request: is it possible to put in some smart redirection so that   
>> old URLs still resolve?  For example:
>>
>> http://www.springframework.org/docs/api/org/springframework/web/  
>> servlet/mvc/SimpleFormController.html
>>
>> I imagine there's lots of articles and such that link to the   
>> documentation and now those links might not resolve.
>>
>> http://www.w3.org/Provider/Style/URI.html ;-)
>>
>> Thanks,
>>
>> Matt
>>
>>
>> On May 5, 2005, at 1:42 PM, Colin Sampaleanu wrote:
>>
>>> I'm happy to announce that a new, enhanced   
>>> http://www.springframework.org is now live!
>>>
>>> The site, sporting a new look and driven by a dynamic content   
>>> management engine, should serve the needs of the Spring community  
>>> much  better. Expect the look and feel, as well as the capabilities  
>>> of the  site, to continue to evolve.
>>>
>>> Thanks to Interface21 for sponsoring the installation, design and   
>>> hosting of the new site.
>>>
>>> (Note that because of DNS caching, it may be up to an hour from the   
>>> time of this email before you can actually see the new site).
>>>
>>> -- 
>>> Colin Sampaleanu
>>> Interface21 Principal Consultant
>>> Spring Training, Consulting and Support - "From the Source"
>>> http://www.springframework.com
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great  
> events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> Springframework-user mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-user

Re: [Springframework-user] Re: [Springframework-developer] New www.springframework.org site is live!

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

The CMS here is Drupal.

It's certainly possible to handle historical URLs, and some already are. 
Most of the site is handled dynamically by Drupal, but
   /dtd
and
  /buttons
is redirected internally (invisibly) by Apache to the new
  http://static.springframework.org
site meant for completely static content like online documentation. It 
was critical to do this to not break DTD URLs and existing button links 
using the images directly from the Spring website.

There is a question of what to do this for however. The old static 
structure was somewhat adhoc and simplistic. If you look at your example
   
http://www.springframework.org/docs/api/org/springframework/web/servlet/mvc/SimpleFormController.html
there's no product name (spring base library vs. webflow vs whatever 
other lib) in there, and there's no version number. Under the new 
structure, this is available as
  
http://static.springframework.org/spring/docs/1.1.5/api/org/springframework/web/servlet/mvc/SimpleFormController.html

Colin

Matt Raible wrote:

> Nice work guys - now we just need to get you to write the CMS using  
> Spring. ;-)  I'm guessing this site uses Plone like the  
> springframework.com site?
>
> One request: is it possible to put in some smart redirection so that  
> old URLs still resolve?  For example:
>
> http://www.springframework.org/docs/api/org/springframework/web/ 
> servlet/mvc/SimpleFormController.html
>
> I imagine there's lots of articles and such that link to the  
> documentation and now those links might not resolve.
>
> http://www.w3.org/Provider/Style/URI.html ;-)
>
> Thanks,
>
> Matt
>
>
> On May 5, 2005, at 1:42 PM, Colin Sampaleanu wrote:
>
>> I'm happy to announce that a new, enhanced  
>> http://www.springframework.org is now live!
>>
>> The site, sporting a new look and driven by a dynamic content  
>> management engine, should serve the needs of the Spring community 
>> much  better. Expect the look and feel, as well as the capabilities 
>> of the  site, to continue to evolve.
>>
>> Thanks to Interface21 for sponsoring the installation, design and  
>> hosting of the new site.
>>
>> (Note that because of DNS caching, it may be up to an hour from the  
>> time of this email before you can actually see the new site).
>>
>> -- 
>> Colin Sampaleanu
>> Interface21 Principal Consultant
>> Spring Training, Consulting and Support - "From the Source"
>> http://www.springframework.com
>

Re: [Springframework-developer] New www.springframework.org site is live!

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

Nice work guys - now we just need to get you to write the CMS using  
Spring. ;-)  I'm guessing this site uses Plone like the  
springframework.com site?

One request: is it possible to put in some smart redirection so that  
old URLs still resolve?  For example:

http://www.springframework.org/docs/api/org/springframework/web/ 
servlet/mvc/SimpleFormController.html

I imagine there's lots of articles and such that link to the  
documentation and now those links might not resolve.

http://www.w3.org/Provider/Style/URI.html ;-)

Thanks,

Matt


On May 5, 2005, at 1:42 PM, Colin Sampaleanu wrote:

> I'm happy to announce that a new, enhanced  
> http://www.springframework.org is now live!
>
> The site, sporting a new look and driven by a dynamic content  
> management engine, should serve the needs of the Spring community much  
> better. Expect the look and feel, as well as the capabilities of the  
> site, to continue to evolve.
>
> Thanks to Interface21 for sponsoring the installation, design and  
> hosting of the new site.
>
> (Note that because of DNS caching, it may be up to an hour from the  
> time of this email before you can actually see the new site).
>
> -- 
> Colin Sampaleanu
> Interface21 Principal Consultant
> Spring Training, Consulting and Support - "From the Source"
> http://www.springframework.com
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great  
> events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] New www.springframework.org site is live!

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

I'm happy to announce that a new, enhanced 
http://www.springframework.org is now live!

The site, sporting a new look and driven by a dynamic content management 
engine, should serve the needs of the Spring community much better. 
Expect the look and feel, as well as the capabilities of the site, to 
continue to evolve.

Thanks to Interface21 for sponsoring the installation, design and 
hosting of the new site.

(Note that because of DNS caching, it may be up to an hour from the time 
of this email before you can actually see the new site).

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

Re: [Springframework-developer] TopLink support

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

Well-spotted, I have deliberately kept this out up to now, because TopLink
has its own Connection acquisition rules (by default lazy; within a write
transaction, not before actual commit).

I've spent some time today to research this a bit further: for a read-write
transaction, TopLink can be forced to start the database transaction early,
which makes it stick with a single JDBC Connection upfront. That JDBC
Connection can be retrieved (through some API hoops), so I've added support
for exposing it as transaction for JDBC access code. A DataSource needs to
specified on TopLinkTransactionManager's "dataSource" property to enable
this.

To be committed later today :-)

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Erwin Vervaet
Sent: Thursday, May 05, 2005 8:57 AM
To: spr...@li...
Subject: Re: [Springframework-developer] TopLink support


> It's modeled somewhat analogously to our Hibernate support, although with
> the important difference that we use a custom SessionFactory interface for
> TopLink (because TopLink does not define such a resource out of the box).
> There are the usual suspects: LocalSessionFactoryBean, TopLinkTemplate,
> TopLinkCallback, TopLinkTransactionManager.

Just wondering, is it possible to mix TopLink DB access and straight JDBC
use in the same transaction, like with the HibernateTransactionManager? If I
understand the JavaDoc this doesn't seem to be the case?

Erwin



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: [Springframework-user] Delayed association of transaction with session

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

One way to make it more elegant is to use an object initialisation callback 
interface. That way the controllers can pass this initialisation strategy 
into the service layer, which will call it to initialize any objects 
("excercizing" the lazy associations) it returns back to the controller. As 
a result you have a situation where

1) the controllers "define" (by implementing the initialisation callback 
interface, mostly using an anonymous inner class) how to initialize the 
objects retreived from the service layer, which can be specific to that 
controller and its views

2) no explosion of methods on the service layer to support all possible 
usage scenarios by the controllers

3) for optimisation you still have the option of defining a specialized 
service method which is backed by a specialized query

Erwin Vervaet
erw...@er...
----- Original Message ----- 
From: "James Cook" <jim...@do...>
To: <spr...@li...>
Sent: Thursday, May 05, 2005 3:11 PM
Subject: RE: [Springframework-developer] Re: [Springframework-user] Delayed 
association of transaction with session


That's the thread where I described a service layer approach that we began
using when we ditched OSIV. We give our web-tier a service layer to interact
with that defines a transactional boundary.

It worked very well for us, except for the problem that Ugo Cei brought up
regarding the ugliness of pre-loading lazy-loaded collections. Not really a
problem, but not so elegant.

jim

> -----Original Message-----
> > There are other workarounds that may be jammed in, but the ones I can
> > think
> > up are not exactly elegant. Perhaps this is simply a case of developer
> > beware; a known side-effect to using the OSIV approach to web
> development.
> > I'd appreciate any advice on whether the framework can be coerced to
> > eliminate one of the remaining flaws in this pattern.
>
> Also take a look at the following discussion, which details more of the
> issues of OSIV:
>
> http://www.newsarch.com/archive/mailinglist/comp/java/springframework/user
> /msg03641.html
>
> Erwin



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Re: [Springframework-user] Delayed association of transaction with session

[James C. <jim...@do...>]

That's the thread where I described a service layer approach that we =
began
using when we ditched OSIV. We give our web-tier a service layer to =
interact
with that defines a transactional boundary.

It worked very well for us, except for the problem that Ugo Cei brought =
up
regarding the ugliness of pre-loading lazy-loaded collections. Not =
really a
problem, but not so elegant.

jim

> -----Original Message-----
> > There are other workarounds that may be jammed in, but the ones I =
can
> > think
> > up are not exactly elegant. Perhaps this is simply a case of =
developer
> > beware; a known side-effect to using the OSIV approach to web
> development.
> > I'd appreciate any advice on whether the framework can be coerced to
> > eliminate one of the remaining flaws in this pattern.
>=20
> Also take a look at the following discussion, which details more of =
the
> issues of OSIV:
>=20
> =
http://www.newsarch.com/archive/mailinglist/comp/java/springframework/use=
r
> /msg03641.html
>=20
> Erwin

RE: [Springframework-developer] Building WebFlow samples

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

I updated the readme.txt instructions.  Please let me know if these could
still be improved.

/*
 * webflow-samples
 *
 * phonebook - central sample demonstrating most webflow features
 * itemlist - demonstrates application transaction tokens and expired flow
cleanup
 * fileupload - demonstrates multipart file upload with webflow
 * birthdate - demonstrates Struts integration and the MultiAction
 * sellitem - demonstrates a wizard with conditional transitions and
continuations
 *
 * @author Keith Donald
 * @since Mar 2005
 * @version $Id: readme.txt,v 1.2 2005/04/11 06:19:53 kdonald Exp $
 */

HOW TO BUILD WEBFLOW SAMPLES - FROM RELEASED DISTRIBUTION

1. copy in the template 'build.properties' file in the same directory as
this file to the root directory of the sample you wish to run.

2. cd to the root directory of the sample you wish to run.

3. tweak the copied 'build.properties' to your environment

4. tweak 'build.bat' to point your environemnt so the ant build system can
execute.

5. run 'build dist' to build the application .war file, ready for
deployment.

6. if tomcat is installed on your system, run 'build tomcat.server.start' to
start it and deploy the
sample application in one step.

7. access the sample at the appropriate URL, e.g
http://localhost:8080/phonebook

HOW TO BUILD WEBFLOW SAMPLES - FROM CVS

From the spring root directory, execute from the command line:

1. build alljars

2. build webflow.jar

3. build webflow.support.jar

4. Proceed with the RELEASED DISTRIBUTION instructions above, customizing
your local build.properties for each sample as necessary.  Note: If all want
to do is build the sample .war file for manual deployment, you shouldn't
have to do any build.properties customization--the default properties will
suffice.  Property customization is only necessary if you have custom paths
to dependent jar files or wish to automate deployment with a local tomcat
installation.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
kat...@ho...
Sent: Thursday, May 05, 2005 1:04 AM
To: spr...@li...
Subject: [Springframework-developer] Building WebFlow samples

I was building the phonebook sample and found it wouldn't compile as the 
sandbox classes were missing. How is everyone else obtaining/generating 
the samples?

I added a patch (see below) which fixes the problem - but there may be 
another approach. What are other doing? :)

If there is a better way, maybe we can improve the build instructions in 
the distro.

Cheers.


Compiling 9 source files to 
C:\work\spring\samples\webflow\phonebook\target\classes
C:\work\spring\samples\webflow\phonebook\src\org\springframework\samples\pho
nebook\web\flow\PersonDetailFlowBuilder.java:18: 
package org.springframework.binding.convert does not exist
import org.springframework.binding.convert.ConversionExecutor;


===================================================================
RCS file: /cvsroot/springframework/spring/builds/build.xml,v
retrieving revision 1.2
diff -u -r1.2 build.xml
--- build.xml	27 Apr 2005 00:14:44 -0000	1.2
+++ build.xml	5 May 2005 04:44:26 -0000
@@ -15,6 +15,7 @@
  		<pathelement location="${target.classes.dir}" />
  		<pathelement location="${commons.logging.jar}" />
  		<pathelement location="${spring.jar}" />
+		<pathelement location="${spring.sandbox.jar}" />
  		<pathelement location="${spring.mock.jar}" />
  	</path>



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Building WebFlow samples

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

The build readme.txt in samples/webflow, which I'm assuming the directions
you're referring to, assumes you're building from a released distribution,
where the webflow .jars have already been built for you...

I guess we should provide a second section of instructions in readme.txt for
building from CVS, too, which would be what Erwin described--requiring you
to build webflow.jar and webflow.support.jar.  Now you could of course just
use the sandbox.jar, but that pulls in a lot of stuff you don't need.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
kat...@ho...
Sent: Thursday, May 05, 2005 1:04 AM
To: spr...@li...
Subject: [Springframework-developer] Building WebFlow samples

I was building the phonebook sample and found it wouldn't compile as the 
sandbox classes were missing. How is everyone else obtaining/generating 
the samples?

I added a patch (see below) which fixes the problem - but there may be 
another approach. What are other doing? :)

If there is a better way, maybe we can improve the build instructions in 
the distro.

Cheers.


Compiling 9 source files to 
C:\work\spring\samples\webflow\phonebook\target\classes
C:\work\spring\samples\webflow\phonebook\src\org\springframework\samples\pho
nebook\web\flow\PersonDetailFlowBuilder.java:18: 
package org.springframework.binding.convert does not exist
import org.springframework.binding.convert.ConversionExecutor;


===================================================================
RCS file: /cvsroot/springframework/spring/builds/build.xml,v
retrieving revision 1.2
diff -u -r1.2 build.xml
--- build.xml	27 Apr 2005 00:14:44 -0000	1.2
+++ build.xml	5 May 2005 04:44:26 -0000
@@ -15,6 +15,7 @@
  		<pathelement location="${target.classes.dir}" />
  		<pathelement location="${commons.logging.jar}" />
  		<pathelement location="${spring.jar}" />
+		<pathelement location="${spring.sandbox.jar}" />
  		<pathelement location="${spring.mock.jar}" />
  	</path>



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] RESTful support

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

Douglas,

I'm working on a project at the moment that is using Spring for REST and 
I'll probably integrate some of my findings into the main codebase if 
they warrant it. So far I have found it extremely simple to build 
RESTful services using Spring out of the box - I just have a few 
framework controllers that parse the request into a DOM Document for XML 
REST services, some that automatically bind XML input to a command 
object etc.

Rob

Douglas Hubler wrote:

>I think RESTful web services are really inline with Spring's philosophy so I was
>wondering if anyone has built RESTful webservices in Spring and if so, how they
>did it.  RESTful advocates claim it's a philosophy, not a library, but I can't
>help but think there's some URL handling classes and basic interfaces that would
>go a long way.
>
>http://rest.blueoxen.net/cgi-bin/wiki.pl  - REST wiki for more info.
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: NEC IT Guy Games.
>Get your fingers limbered up and give it your best shot. 4 great events, 4
>opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
>win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

Re: [Springframework-developer] Re: [Springframework-user] Delayed association of transaction with session

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

> There are other workarounds that may be jammed in, but the ones I can 
> think
> up are not exactly elegant. Perhaps this is simply a case of developer
> beware; a known side-effect to using the OSIV approach to web development.
> I'd appreciate any advice on whether the framework can be coerced to
> eliminate one of the remaining flaws in this pattern.

Also take a look at the following discussion, which details more of the 
issues of OSIV:

http://www.newsarch.com/archive/mailinglist/comp/java/springframework/user/msg03641.html

Erwin 

Re: [Springframework-developer] Building WebFlow samples

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

I just use the instructions you find at 
http://opensource.atlassian.com/confluence/spring/display/WEBFLOW/Home.
Basically:

cd \my\dir\spring
build alljars
build webflow.jar
build webflow.support.jar
cd samples\webflow\phonebook
build dist

Silimar for other samples.

Erwin Vervaet
----- Original Message ----- 
From: <kat...@ho...>
To: <spr...@li...>
Sent: Thursday, May 05, 2005 7:04 AM
Subject: [Springframework-developer] Building WebFlow samples


>I was building the phonebook sample and found it wouldn't compile as the 
>sandbox classes were missing. How is everyone else obtaining/generating the 
>samples?
>
> I added a patch (see below) which fixes the problem - but there may be 
> another approach. What are other doing? :)
>
> If there is a better way, maybe we can improve the build instructions in 
> the distro.
>
> Cheers.
>
>
> Compiling 9 source files to 
> C:\work\spring\samples\webflow\phonebook\target\classes
> C:\work\spring\samples\webflow\phonebook\src\org\springframework\samples\phonebook\web\flow\PersonDetailFlowBuilder.java:18: 
> package org.springframework.binding.convert does not exist
> import org.springframework.binding.convert.ConversionExecutor;
>
>
> ===================================================================
> RCS file: /cvsroot/springframework/spring/builds/build.xml,v
> retrieving revision 1.2
> diff -u -r1.2 build.xml
> --- build.xml 27 Apr 2005 00:14:44 -0000 1.2
> +++ build.xml 5 May 2005 04:44:26 -0000
> @@ -15,6 +15,7 @@
>  <pathelement location="${target.classes.dir}" />
>  <pathelement location="${commons.logging.jar}" />
>  <pathelement location="${spring.jar}" />
> + <pathelement location="${spring.sandbox.jar}" />
>  <pathelement location="${spring.mock.jar}" />
>  </path>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
> 

Re: [Springframework-developer] TopLink support

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

> It's modeled somewhat analogously to our Hibernate support, although with
> the important difference that we use a custom SessionFactory interface for
> TopLink (because TopLink does not define such a resource out of the box).
> There are the usual suspects: LocalSessionFactoryBean, TopLinkTemplate,
> TopLinkCallback, TopLinkTransactionManager.

Just wondering, is it possible to mix TopLink DB access and straight JDBC 
use in the same transaction, like with the HibernateTransactionManager? If I 
understand the JavaDoc this doesn't seem to be the case?

Erwin 

[Springframework-developer] Building WebFlow samples

[<kat...@ho...>]

I was building the phonebook sample and found it wouldn't compile as the 
sandbox classes were missing. How is everyone else obtaining/generating 
the samples?

I added a patch (see below) which fixes the problem - but there may be 
another approach. What are other doing? :)

If there is a better way, maybe we can improve the build instructions in 
the distro.

Cheers.


Compiling 9 source files to 
C:\work\spring\samples\webflow\phonebook\target\classes
C:\work\spring\samples\webflow\phonebook\src\org\springframework\samples\phonebook\web\flow\PersonDetailFlowBuilder.java:18: 
package org.springframework.binding.convert does not exist
import org.springframework.binding.convert.ConversionExecutor;


===================================================================
RCS file: /cvsroot/springframework/spring/builds/build.xml,v
retrieving revision 1.2
diff -u -r1.2 build.xml
--- build.xml	27 Apr 2005 00:14:44 -0000	1.2
+++ build.xml	5 May 2005 04:44:26 -0000
@@ -15,6 +15,7 @@
  		<pathelement location="${target.classes.dir}" />
  		<pathelement location="${commons.logging.jar}" />
  		<pathelement location="${spring.jar}" />
+		<pathelement location="${spring.sandbox.jar}" />
  		<pathelement location="${spring.mock.jar}" />
  	</path>

[Springframework-developer] spring build.260 Build Successful

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

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

Re: [Springframework-developer] Re: [Springframework-user] Delayed association of transaction with session

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

James,

> The invalid object X will be inadvertently persisted to the database in
step
> 8. It also occurs in a manner that can be very hard to anticipate or debug
> depending on how step 8 is triggered.
>
> The view component that loads the reference objects (8) does not even have
> to be the same view that invokes the lazy load (7). For example, the
> developer may be using sitemesh or tiles and a page composition component
> may have triggered (8).

Yes, that risk is unfortunately hard to avoid. What you need to here is to
mark all your reference data access operations as "readOnly" in the Spring
transaction demarcation, to suppress the flush there. However, if you wanted
to execute a read-write transaction after you modified the loaded Hibernate
object, you would have the same problem again... "readOnly" helps to keep
the risk low, but it does not avoid it completely.

> One technique to address this problem might be to clear the session
*prior*
> to the start of a transaction. This is not ideal, because sometimes the
> controller may wish to invoke multiple transactional methods without
losing
> the session state.

Session.clear is a very strong operation: it essentially evicts all loaded
objects from the first-level cache. This has the effect of clearing pending
modifications to persistent objects, but also of making all existing
persistent instances invalid and not capable of lazy loading anymore.
Alternatively, you could evict specific objects from the Session - but those
wouldn't be lazy loading capable anymore either.

So I'm afraid there is no proper 100% solution for this problem: If you
modify a persistent object within OSIV in "single session" mode and do not
want to persist those changes in the same request, make sure that all
transactions that follow within the same request are read-only.

The only other alternative that comes to my mind is OSIV in "deferred close"
mode, with Hibernate3 merge instead of saveOrUpdate/update. This should work
pretty well, although I haven't battle-tested that combination yet. In
particular, merge should not show the side effects that saveOrUpdate has on
persistent objects that are still registered with a different Hibernate
Session.

> I think OJB also handles lazy-loading differently than Hibernate, but I
have
> only read about it. Seems like OJB isn't gaining a foothold.

Yes, OJB handles this more relaxed too, and so does iBATIS SQL Maps. It's
only Hibernate and JDO that enforce such strict requirements on lazy
loading. The root of the problem is that they tie lazy loading to their
persistent object lifecycle and change detection machinery, which the others
don't. TopLink is the best example that this can be designed differently
(with relaxed lazy loading), while offering similar powers as Hibernate and
JDO.

Juergen

[Springframework-developer] TopLink support

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

Hi everybody,

In case you've been wondering what I was working on so busily... we now have
fully integrated TopLink support in our CVS, including a TopLink
implementation of PetClinic's persistence layer :-) Many thanks to Jim Clark
from Oracle who implemented the original version, and of course to Oracle
for granting the submission!

It's modeled somewhat analogously to our Hibernate support, although with
the important difference that we use a custom SessionFactory interface for
TopLink (because TopLink does not define such a resource out of the box).
There are the usual suspects: LocalSessionFactoryBean, TopLinkTemplate,
TopLinkCallback, TopLinkTransactionManager.

I've documented the TopLink data access operations quite extensively,
because the semantics are significantly different from Hibernate's. For
example, TopLink uses a shared object cache as second-level cache, in
contrast to Hibernate and JDO which only hold flat data there. This leads to
some very important differences in the lifecycle of persistent objects.

An important distinction is between working with a TopLink Session
(read-only) and working with a TopLink UnitOfWork (write operations). Of
course, our TopLink support allows for both in callback style. The
convenience operations defined on TopLinkTemplate allow for working with
both too, either implicitly determined through the current transaction
status or explicitly determined through a "enforceReadOnly" argument.

Notably, there is *no* OpenSessionInViewFilter or
OpenSessionInViewInterceptor for TopLink: it is simply not necessary.
TopLink will automatically apply appropriate lazy loading, whether within an
active Session or outside of it.

Aside from the deployment-ready TopLink persistence layer, the "petclinic"
directory also contains the TopLink Mapping Workbench project that the
mapping XML file was created with. You can simply open the project file in
with any TopLink Mapping Workbench implementation and have a visual few on
the mappings.

For licensing reasons, we only ship a toplink-api.jar that we can compile
against. To run the PetClinic web application or its test suite, a full
toplink.jar and xmlparserv2.jar (both from the TopLink distribution) need to
be dropped into the "lib/toplink" directory (or the deployed "WEB-INF/lib"
directory).

Finally, PetClinic's TopLink layer is currently not able to properly insert
objects, due to TopLink's default HSQLPlatform implementation: we need a
special subclass of this to leverage HSQLDB's identity columns. Such a
subclass is already committed but not fully active yet, simply because we
need some additional methods exposed in our toplink-api.jar to be able to
compile it. This should be resolved by tonight; everything else should
already work!

Juergen

[Springframework-developer] RESTful support

[Douglas H. <dh...@pi...>]

I think RESTful web services are really inline with Spring's philosophy so I was
wondering if anyone has built RESTful webservices in Spring and if so, how they
did it.  RESTful advocates claim it's a philosophy, not a library, but I can't
help but think there's some URL handling classes and basic interfaces that would
go a long way.

http://rest.blueoxen.net/cgi-bin/wiki.pl  - REST wiki for more info.

RE: [Springframework-developer] SWF - Locale

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

With Spring 1.2 you shouldn't have to worry about the Locale, at least when
using a Spring message source.  It'll automatically pickup the Locale from a
thread-bound LocaleContext.

To access it programmatically, use the LocaleContextHolder.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Will Butler
Sent: Tuesday, May 03, 2005 10:40 AM
To: spr...@li...
Subject: [Springframework-developer] SWF - Locale

How can I get the current locale in a spring web flow action?

- Will


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: [Springframework-user] Delayed association of transaction with session

[James C. <jim...@do...>]

That's the best summary yet, Juergen. Thanks.

> In case of a rollback, the Session will receive a clear() call which
> resets all of its pending updates/deletes. This avoids side effects=20
> from dirty state created during the transaction that has just been=20
> rolled-back. Any further transactions can still properly load and=20
> modify persistent objects and expose them to views, with lazy=20
> loading still working.

I like the fact that you clear the session on rollback. Perhaps that =
same
logic could be applied to prevent a potential side-effect of this =
pattern.

Here is a series of steps to reproduce an unintentional save of an =
object in
invalid state.

1. Browser request made, Hibernate session created, web controller
instantiated.
2. Controller loads object X.
   2a. tx.begin
   2b. X =3D session.load(id, class)
   2c. session.flush
   2d. tx.commit
3. X is now a detached object in the controller.
4. Apply request properties against X.
5. Validate X.
6. X is invalid, return to view.
7. View invokes lazy-load of a collection on X (no prob)
8. Some component of the view needs a collection of reference objects.
   8a. View calls controller.getReferences()
   8b. tx.begin
   8c. refs =3D session.find("from somereference")
   8d. session.flush()
   8e. tx.commit

The invalid object X will be inadvertently persisted to the database in =
step
8. It also occurs in a manner that can be very hard to anticipate or =
debug
depending on how step 8 is triggered.

The view component that loads the reference objects (8) does not even =
have
to be the same view that invokes the lazy load (7). For example, the
developer may be using sitemesh or tiles and a page composition =
component
may have triggered (8).

One technique to address this problem might be to clear the session =
*prior*
to the start of a transaction. This is not ideal, because sometimes the
controller may wish to invoke multiple transactional methods without =
losing
the session state.

There are other workarounds that may be jammed in, but the ones I can =
think
up are not exactly elegant. Perhaps this is simply a case of developer
beware; a known side-effect to using the OSIV approach to web =
development.
I'd appreciate any advice on whether the framework can be coerced to
eliminate one of the remaining flaws in this pattern.

> BTW, TopLink is *very* different in that respect: while it does have a
> Session concept too, it handles persistent object lifecycle and in
> particular lazy loading very differently (there is no need for Open
> Session in View there in the first place, as lazy loading will always
> work).

I think OJB also handles lazy-loading differently than Hibernate, but I =
have
only read about it. Seems like OJB isn't gaining a foothold.

[Springframework-developer] SWF - Locale

[Will B. <wil...@ra...>]

How can I get the current locale in a spring web flow action?

- Will

[Springframework-developer] Re: [Springframework-user] Delayed association of transaction with session

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

James,

Yes, this is essentially how Spring's OpenSessionInViewFilter/Interceptor
has been working  since its inception - in its "single session mode". I'll
use the opportunity to discuss this in some detail.

OpenSessionInViewFilter/Interceptor will create a Hibernate Session (without
a transaction) at the start of request processing and close it after
completion of request processing. Each demarcated transaction will take the
existing Hibernate Session and begin a transaction on it, flushing and
committing at the end of the demarcated transasction. Any number of such
transactions can be performed within the same request, on the same Session.

In case of a rollback, the Session will receive a clear() call which resets
all of its pending updates/deletes. This avoids side effects from dirty
state created during the transaction that has just been rolled-back. Any
further transactions can still properly load and modify persistent objects
and expose them to views, with lazy loading still working.

We strongly recommend *against* flushing at request completion. Neither
OpenSessionInViewFilter or OpenSessionInViewInterceptor do this, unless you
create a custom subclass with an explicit flush call. The recommendation is
to only flush at the end of transactions but *never* after view rendering
has started. OpenSessionInViewFilter/Interceptor set the Session to
FlushMode.NEVER outside transactions, to suppress implicit flushing.

For completeness' sake: Aside from transactions,
OpenSessionInViewInterceptor also offers the option to flush after
controller execution, right before view rendering starts. Spring's
HandlerInterceptor gives such a specific callback, but the general Servlet
Filter mechanism doesn't, so we cannot provide this for
OpenSessionInViewFilter. It's preferable to rely on demarcated transactions
instead, in general.

-----

As an alternative to the "single session mode" as discussed above,
OpenSessionInViewFilter/Interceptor also offers a "deferred close mode"
which works quite differently but achieves a similar effect: Each
transaction will still open its own Hibernate Session there, but such a
Session won't be closed at transaction completion. Instead, each of those
Sessions will be kept open until view rendering, to allow for lazy loading.

The main disadvantage of the "deferred close mode" is that you cannot
associate the same persistent object with two transactions (with both
Hibernate Sessions still open): that is, you cannot load a persistent object
in one transaction and call "saveOrUpdate" for it in another transaction.
What you can do, though, is to store such objects through Hibernate3's
"merge": so "deferred close mode" might actually become more viable with
Hibernate3.

-----

I guess the most important advice (which you're of course already aware of)
is: Keep your transactions limited to the business layer or to controller
execution - never keep transactions open during view rendering!

All changes to persistent objects need to be flushed before view rendering
starts: the view should receive independent objects, without the risk of
accidental changes getting persisted. Furthermore, database locks need to be
released early, *before* starting to render a view: rendering is a
potentially intensive I/O operation that might even block in case of
congestion.

Interestingly, the Hibernate team themselves (and others) tend to ignore
this and simply recommend a Servlet Filter that wraps the entire request
processing with a JTA transaction, committing *after* view rendering. In
particular with Hibernate3's auto-flush and auto-close for JTA transactions,
they seem to  believe that this is all you need...

I guess part of the Hibernate team's argumentation is that you should never
do database access outside transactions. As a consequence, lazy loading
outside transactions and hence an Open Session in View without transaction
is bad. In my opinion, the tradeoff of non-transactional lazy loading is
absolutely preferable: it's much more important to flush changes and release
database locks before view rendering starts.

BTW, TopLink is *very* different in that respect: while it does have a
Session concept too, it handles persistent object lifecycle and in
particular lazy loading very differently (there is no need for Open Session
in View there in the first place, as lazy loading will always work). JDO on
the other hand is rather similar to Hibernate, with even stricter lifecycle
requirements (Spring ships an OpenPersistenceManagerInViewFilter/Interceptor
for JDO too).

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf Of
James Cook
Sent: Friday, April 22, 2005 9:54 PM
To: spr...@li...
Subject: [Springframework-user] Delayed association of transaction with
session


Jason (from WebWork) has been working up an example demonstrating
basic CRUD functionality, and he is using the Open Session In View
(OSIV) filter which I have shunned in favor of clearly demarcated
transactional boundaries.

In his example however, there is a twist that I haven't seen yet. He
creates the Hibernate session without a transactional context.
Whenever he performs a direct load or update to a persistent object,
he creates a transaction, executes the session.save() [or whatever],
and commits the transaction. The session is flushed at the end of the
transaction.

When the view renders it can access any of the objects in the
Hibernate session, and use lazy-loaded collections. When the request
completes, the OSIV filter does *not* perform a flush.

My question is whether Spring automatically works this way? For example:

1. Will the OSIV filter create a Hibernate Session without a
transaction starting?
2. When a transactional method is invoked, will a new transaction be
created and associated with the already created Hibernate session?
3. When this transactional method completes successfully, will it
flush the session and commit the transaction?
4. Can I repeat #2-#3 any number of times against the same session?
5. If the transactional method is not successful and a rollback occurs
(for some valid business reason, not a HibernateException), does the
Hibernate Session remain accessible and complete?

This seems like a decent compromise between OSIV and respect for
transactional boundaries for the simplest of applications. There are
still gotchas, (lazy-loaded collections executed outside of a
transaction, objects in the session that may not reflect the state of
the database, dirty objects that are not meant to be persisted, could
magically persist themselves on an innocent call from the view to a
transaction-bound method), but they could be effectively managed if
the app was very simple.


-------------------------------------------------------
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_ide95&alloc_id396&op=ick
_______________________________________________
Springframework-user mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-user

[Springframework-developer] spring build.259 Build Successful

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

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

RE: [Springframework-developer] [webflow] JavaServer Faces Integration -- Proposed Requirements and Approach

[Boyce, K. G. <Kei...@bc...>]

Sound's pretty comprehensive to me.=0D

Has any thought been given to portlet integration supported by webflow?=0D

Also as I understand jsf when you show a jsf view the view is a jsp
rather than a url that is mapped to a jsp page. What are your thoughts
on these issues?=0D

Finally some work is being done on a taglib for Spring similar to struts
taglib. Are there any interactions that need to be considered here (for
instance if both jsf and spring taglibs are together on a single jsp?

Garry

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Craig McClanahan
Sent: Monday, May 02, 2005 1:56 AM
To: Spring Framework Developers
Subject: [Springframework-developer] [webflow] JavaServer Faces
Integration -- Proposed Requirements and Approach

Sorry for a later initial post than I had intended -- life is never as
calm as one would hope.  I'd like to use this message to kick off
discussions around a high quality integration of Spring WebFlow with
JavaServer Faces, which I will also volunteer to help build and
maintain, and then contribute into the Spring source code base so that
everyone can benefit from it.

As background for understanding what is required to accomplish this, I
have implemented a relatively simple "dialog" mechanism (heavily
inspired by SWF) into Shale -- my next generation web application
framework that is built on top of JSF's extensible front controller
facilities (rather than treating JSF as just a view tier technology).=0D
I would like to briefly explain what I've done there, and use it to
motivate further discussion about what the requirements for SWF-JSF
integration should be, and some proposed solutions based on what I've
learned so far.  However, I'm definitely going to need assistance from
Keith, Erwin, and others that are MUCH more familiar with Spring and SWF
than I am :-)


BACKGROUND - SHALE DIALOGS

Shale is a next generation web framework that I proposed to the Struts
community as "the architecture for Struts 2.x".  It did not get accepted
(by the other developers) as that, but it *did* get accepted as a formal
Struts subproject so that it can share the community already built up
around Struts, and attempt to build a community of its own.

The starting point for information about Shale is the wiki page on it:

  http://wiki.apache.org/struts/StrutsShale

Shale is (AFAIK so far) unique among Java-based web application
frameworks in that it is designed *assuming* that JavaServer Faces front
controller facilities will be used, rather than treating JSF as just a
view tier technology (where there are integrations with many web
frameworks already, including Spring MVC and Struts 1.x).  This
assumption, as it turns out, leads to dramatically less work to do as a
framework developer -- there's a lot of beef already in existence, plus
pluggability extension points that allow a fully featured framework to
be built around the core of what JSF 1.x supplies.

In turn, that has let me focus on providing value add features on top of
the bare bones controller capabilities in JSF already.  One primary
motivation was implementing the "view helper" design pattern (also
popularized in the application model that Visual Studio supports for
ASP.NET and VB.NET applications), epitomized here in the ViewController
interface.  This particular pattern is synergistic with the dialog
support discussed below, because it tends to reduce the number of action
states required, but that's really not the focus of ths particular
discussion.

On my original set of goals for Shale was support for "dialogs" --
interactions with the user that were "longer than a request, but shorter
than a session".  I had made some initial clumsy attempts at adding a
JSF flavor around this idea.  Principally, that meant sharing a JSF
"backing bean" (the Java code where you put event handlers associated
with a page) between all the pages of a particular dialog.=0D
It worked, but it was pretty clumsy.

Then, I had started hearing about SWF, and got the chance to see Keith's
presentation of it at TSSJS in Las Vegas last March.  It was obviously a
*much* better approach, so I set about learning what I could about it.
I tend to learn by doing, so I created a fairly simple implementation of
the same concept in Shale, but kept the name "dialog" (so that "flow"
would be available when SWF was eventually integrated :-).  The dialog
support is in package "org.apache.shale.dialog" of the core library --
and doesn't actually have any dependencies on other parts of Shale,
although applications will benefit if they take advantage of those.  The
"use cases" example app uses this facility in the
"org.apache.shale.usecases.profile"
package where two dialogs (Log On and Edit Profile) are used.  The
package Javadocs for this package include state diagrams for these two
dialogs (if you've read the SWF "Practical Guide" page, you'll know
exactly how this translates to dialog definitions ;-).

Compared to SWF, dialogs are different in the following ways:

* Action states are encapsulated as a JSF "method binding expression",
which
  is an EL expression pointing at a public method of some bean (typicaly
a JSF
  managed bean) that takes no arguments and returns a String that is
interpreted
  as the outcome that drives the next transition.  This method signature
happens
  to match the signature used for an "action" that is invoked by a JSF
command
  component (such as a submit button), and JSF already provides the
expression
  evaluation machinery, so it was natural to support a familiar
approach.

* View states are encapsulated as the rendering of a JSF-based response,
  *plus* the processing (through the normal JSF request processing
lifecycle)
  of the subsequent submit.  The logical outcome string returned by the
submit
  action that was ultimately invoked drives the transition from the view
state to
  the subsequent state within this dialog.

* A facility is provided such that the state information specific to a
particular
  dialog may be exposed (as a property on a session scoped bean) but
automatically
  cleaned up when the dialog completes.  This is done by calling
setData(Object)
  on the Status instance (in session scope) where the dialog facility
keeps track
  of the current state of the dialog being executed.  This "data"
object is pushed
  onto a stack when a nested dialog is entered, and popped off when the
dialog
  is completed -- which means the application does not need to be
concerned with
  throwing away a session scope attribute when the outermost dialog is
finished.

* As a happy consequence of the above feature, pages containing JSF
components
  can use value binding expressions to store information in this data
object, without
  any regard to which dialog is being executed (or how deeply nested it
is).  In the
  Shale sample application, the "Edit Profile" dialog has a "fullName"
field that is bound
  to a property of the local state object like this:

    <h:inputText id=3D"fullName" value=3D"#{dialog.data.fullName}"/>

  where "dialog" is the session scoped bean containing the state of the
dialog
  computation, and "data" is the general property a dialog can use to
store state
  specific to this dialog.  The state object will be thrown away for you
when the
  dialog completes -- essentially creating a "transaction scope" even
though no
  such thing is (yet) supported by the Servlet API.

* (Recently added) it is possible to define transitions that are global
to an entire
  dialog, rather than having to explicitly define them all inside a
state definition.
  This is exactly analogous to the way that Struts allows you to define
global
  <forward> elements (for the entire application) that can get
overridden on a
  per-action basis by a local <forward> element.

The idea of configuring dialogs and using these facilities works out
quite well ("well, duh" says anyone already familiar with SWF :-).  It
also turned out to be incredibly simple to implement -- one of the JSF
extension points is the NavigationHandler API, which the framework
invokes after the application action returns.  It is used to drive
navigation to another page (or back to the same page, if the logical
outcome is null).  The key method signature is:

    public void handeNavigation(FacesContext context, String fromAction,
String outcome);

where "context" is an encapsulation of the state of the current request,
"fromAction" lets you distinguish between submit buttons (that might
return the same outcome) on the same form, and "outcome"
is the logical outcome that is returned by the action method.

By default, JSF supplies a mechanism that analyzes a set of navigation
rules (defined in a faces-config.xml file) to choose the next view
(typically a JSP page, but that's by no means the only option) to be
rendered.  However, this is an extension point where a framework can
provide value added facilities, or delegate to the standard machinery if
it wants to.

As currently implemented in Shale, the custom NavigationHandler provides
the following facilities:

* When no dialog is being executed, delegate to the standard
  JSF NavigationHandler implementation (so that everything the
  developer knows about JSF navigation happens as expected).

* A dialog named "xxx" is entered when an action returns a logical
  outcome of "dialog:xxx".  This approach required no change to any
  JSF (or JSF-called) APIs -- it's just a specialized interpretation of
  the logical outcome string.

* Once a dialog is entered, state transitions are managed by the custom
  NavigationHandler implementation
(org.apache.shale.dialog.faces.DialogNavigationHandler)
  in a manner very similar to what a SWF Controller does.  This includes
  the ability to nest dialogs (just like SWF can nest flows).

The end result is an environment with some very important benefits
resulting:

* Outside of the dialogs world, standard JSF things work in the usual
way.

* Dialogs can reuse actions and view states (including those that are
also
  accessed directly via standard JSF facilities), because the
interpretation of
  the logical outcome is specialized per dialog.

* As with SWF, the configuration of a dialog (or a flow) is very much
amenable
  to tool-aided support like graphical drag-n-drop development of the
overall flow --
  as well as for more formal UML-based tool support.

* Because of the other capabilities provided by Shale, an application
will typically
  need fewer "setup" action states (because the prerender() method of a
  ViewController can take many of these responsibilities) and less work
in
  what is typically a "bindAndValidate" action in Spring (because JSF
has its
  own support for validation processing that preceeds such a state).
But these
  are just icing on the cake -- the key values of having managed dialogs
are
  independent of Shale.


PROPOSED SWF-JSF INTEGRATION REQUIREMENTS

Given what I've learned from the above investigations, then, I'd like to
propose the following as requirements to be met by an integration
between SWF and JSF:

* When a flow is *not* being exected, all the standard JSF navigation
capabilities
  will work as expected.

* Execution of a JSF action method can cause a SWF flow to be entered,
by
  returning a suitably encoded logical outcome (perhaps "flow:xxx" or
"swf:xxx" to
  invoke a flow named "xxx").  In addition, other standard approaches to
entering
  a flow will also work, of course.

* Zero or more flows may reuse the same JSF pages (and backing beans).
This
  implies that the flow management facility will take over the
interpretation of logical
  outcomes from standard JSF action methods, which would otherwise drive
the
  standard navigation facilities of JSF.

* There should be a mechanism to push a local state object onto a stack,
and
  have it popped off on dialog completion (as Shale does) so that
applications do
  not have to worry about it.  This is not mission critical (and indeed
there might be
  facilities for this already that I haven't discovered yet :-), but it
is very important
  to usability.

* JSF applications using SWF must be able to leverage all of the
sophisticated
  transition management capabilities that SWF supports (as opposed to
the simple
  deterministic model that Shale currently provides).

* When executing a flow, a JSF view state will cause the corresponding
JSF view
   to be rendered, *and* the flow will be suspended until the subsequent
JSF form
  submit occurs.  The logical outcome from the action method that is
invoked for
  the appropriate submit button will be used to drive the next
transition.

    - IMPLICATION:  If JSF validation failures occur, the current page
will
      be redisplayed without ever invoking the application action
method; implying
      that the current state will remain the same.  This is typically
the desired result,
      but requires no explicit transition management in a JSF-based
application.

* While executing a flow, non-JSF view states should be supported as
well
  (this probably comes out of the box, but it needs to be called out).


PROPOSED IMPLEMENTATION APPROACH:

Here's where I really need some help from you guys :-).

It seems that all of the above requirements can be met, in a manner
fairly similar to what I did with Shale's dialogs, by implementing a
custom JSF NavigationHandler with the following features:

* When not currently executing a flow, standard JSF navigation is
performed.

* When a logical outcome of the form "flow:xxx" is handed to the
handleNavigation()
   method, the flow named "xxx" is invoked at its start state.

* While a flow is invoking action and subflow states, the usual SWF
processing
  will occur.

* When a flow invokes a view state for a non-JSF page, the usual SWF
processing
  will occur.

* When a flow invokes a view state for a JSF page, the appropriate JSF
incantations
  to create the corresponding view, and render it, will be invoked.=0D
Further, the state
  of this flow will be suspended until JSF processes a subsequent form
submit, and
  invokes an application action that returns a logical outcome.  This
outcome will be
  the one used to drive a transition from the current view state to some
other state
  in the current flow (or exiting the flow, if this is also an end
state).

* I don't see anything like this in the current APIs (but that doesn't
mean it doesn't
  exist :-), but it would be very useful to be able to push and pop the
current model
  data for a flow in a manner similar to what Shale does.  In
particular, this facilitates
  the use of JSF value binding expressions that have a constant content
regardless
  of nested flow execution.

* The implementation should be packaged in a JAR file that contains a
  "META-INF/faces-config.xml" resource that automatically configures the
integration
  with JSF, with no required changes to web.xml (I can help you
accomplish the same
  for the existing JSF managed bean integration as well).

Does this sound compatible with what you guys have had in mind for SWF?

Craig McClanahan


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events,
4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


This message is a PRIVATE communication.
If you are not the intended recipient, please do not read, copy,
or use it, and do not disclose it to others. Please notify the
sender of the delivery error by replying to this message, and then
delete it from your system. Thank you.

RE: [Springframework-developer] [webflow] JavaServer Faces Integration -- Proposed Requirements and Approach

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

Craig,

I just gave this a read twice and will another review later today (I have to
get an article on SWF to TSS by noon ;-))

In general, I like your approach and it seems like it will work quite
elegantly.  I can definitely tell you've thought it out :-)

Regarding:
-> I don't see anything like this in the current APIs (but that doesn't
mean it doesn't exist :-), but it would be very useful to be able to push
and pop the current model  data for a flow in a manner similar to what Shale
does.  In particular, this facilitates the use of JSF value binding
expressions that have a constant content regardless of nested flow
execution.

If I hear you correctly, this is indeed already present in SWF.  SWF has the
notion of 'backing beans' (we call them attributes, as they could be simple
scalars, too) storable in flow scope or request scope.  Each FlowSession on
the FlowExecutionStack get its own flowScope structure.  Anything in
flowScope is automatically cleaned up when its FlowSession ends and is
popped off the stack (triggered when the active flow session reaches an end
state).

(Sidenote: I'd recommend checking out the Scope type, and the
FlowExecutionStack/FlowSession implementations, and then the
InternalRequestContext managed from the central 'start' and 'signalEvent'
operations).

In addition, view clients like JSF components are kept unaware of scoping by
our 'model' concept.  When a ViewState is entered and control is returned to
the caller (we say the flow is 'paused'), a ViewDescriptor is returned that
provides the name of a view to render and all supporting model data (a map
of name/value pairs) necessary to render it.  The data in the model map is
the union of everything in flowScope and requestScope, plus some additional
flow metadata (e.g the flowExecutionId, needed to refer back to a paused
flow on subsequent requests).

Then, depending on the flow execution environment, the model map may be
exported for consistent, easy access from the views during rendering.  For
example, in traditional HTTP MVC environments like Struts and Spring MVC,
the model map is simply exported into the request as request attributes.
Portlets have the model exported somewhere else.  What would make sense for
JSF? Standard request attributes?

The only downside to this approach I see is the potential for name
collisions in different scopes, but I have not found this to be an issue in
practice.
 
Great to see this moving forward!

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Craig McClanahan
Sent: Monday, May 02, 2005 1:56 AM
To: Spring Framework Developers
Subject: [Springframework-developer] [webflow] JavaServer Faces Integration
-- Proposed Requirements and Approach

Sorry for a later initial post than I had intended -- life is never as
calm as one would hope.  I'd like to use this message to kick off
discussions around a high quality integration of Spring WebFlow with
JavaServer Faces, which I will also volunteer to help build and
maintain, and then contribute into the Spring source code base so that
everyone can benefit from it.

As background for understanding what is required to accomplish this, I
have implemented a relatively simple "dialog" mechanism (heavily
inspired by SWF) into Shale -- my next generation web application
framework that is built on top of JSF's extensible front controller
facilities (rather than treating JSF as just a view tier technology). 
I would like to briefly explain what I've done there, and use it to
motivate further discussion about what the requirements for SWF-JSF
integration should be, and some proposed solutions based on what I've
learned so far.  However, I'm definitely going to need assistance from
Keith, Erwin, and others that are MUCH more familiar with Spring and
SWF than I am :-)


BACKGROUND - SHALE DIALOGS

Shale is a next generation web framework that I proposed to the Struts
community as "the architecture for Struts 2.x".  It did not get
accepted (by the other developers) as that, but it *did* get accepted
as a formal Struts subproject so that it can share the community
already built up around Struts, and attempt to build a community of
its own.

The starting point for information about Shale is the wiki page on it:

  http://wiki.apache.org/struts/StrutsShale

Shale is (AFAIK so far) unique among Java-based web application
frameworks in that it is designed *assuming* that JavaServer Faces
front controller facilities will be used, rather than treating JSF as
just a view tier technology (where there are integrations with many
web frameworks already, including Spring MVC and Struts 1.x).  This
assumption, as it turns out, leads to dramatically less work to do as
a framework developer -- there's a lot of beef already in existence,
plus pluggability extension points that allow a fully featured
framework to be built around the core of what JSF 1.x supplies.

In turn, that has let me focus on providing value add features on top
of the bare bones controller capabilities in JSF already.  One primary
motivation was implementing the "view helper" design pattern (also
popularized in the application model that Visual Studio supports for
ASP.NET and VB.NET applications), epitomized here in the
ViewController interface.  This particular pattern is synergistic with
the dialog support discussed below, because it tends to reduce the
number of action states required, but that's really not the focus of
ths particular discussion.

On my original set of goals for Shale was support for "dialogs" --
interactions with the user that were "longer than a request, but
shorter than a session".  I had made some initial clumsy attempts at
adding a JSF flavor around this idea.  Principally, that meant sharing
a JSF "backing bean" (the Java code where you put event handlers
associated with a page) between all the pages of a particular dialog. 
It worked, but it was pretty clumsy.

Then, I had started hearing about SWF, and got the chance to see
Keith's presentation of it at TSSJS in Las Vegas last March.  It was
obviously a *much* better approach, so I set about learning what I
could about it.  I tend to learn by doing, so I created a fairly
simple implementation of the same concept in Shale, but kept the name
"dialog" (so that "flow" would be available when SWF was eventually
integrated :-).  The dialog support is in package
"org.apache.shale.dialog" of the core library -- and doesn't actually
have any dependencies on other parts of Shale, although applications
will benefit if they take advantage of those.  The "use cases" example
app uses this facility in the "org.apache.shale.usecases.profile"
package where two dialogs (Log On and Edit Profile) are used.  The
package Javadocs for this package include state diagrams for these two
dialogs (if you've read the SWF "Practical Guide" page, you'll know
exactly how this translates to dialog definitions ;-).

Compared to SWF, dialogs are different in the following ways:

* Action states are encapsulated as a JSF "method binding expression", which
  is an EL expression pointing at a public method of some bean (typicaly a
JSF
  managed bean) that takes no arguments and returns a String that is
interpreted
  as the outcome that drives the next transition.  This method signature
happens
  to match the signature used for an "action" that is invoked by a JSF
command
  component (such as a submit button), and JSF already provides the
expression
  evaluation machinery, so it was natural to support a familiar approach.

* View states are encapsulated as the rendering of a JSF-based response,
  *plus* the processing (through the normal JSF request processing
lifecycle)
  of the subsequent submit.  The logical outcome string returned by the
submit
  action that was ultimately invoked drives the transition from the
view state to
  the subsequent state within this dialog.

* A facility is provided such that the state information specific to a
particular
  dialog may be exposed (as a property on a session scoped bean) but
automatically
  cleaned up when the dialog completes.  This is done by calling
setData(Object)
  on the Status instance (in session scope) where the dialog facility
keeps track
  of the current state of the dialog being executed.  This "data"
object is pushed
  onto a stack when a nested dialog is entered, and popped off when the
dialog
  is completed -- which means the application does not need to be concerned
with
  throwing away a session scope attribute when the outermost dialog is
finished.

* As a happy consequence of the above feature, pages containing JSF
components
  can use value binding expressions to store information in this data
object, without
  any regard to which dialog is being executed (or how deeply nested
it is).  In the
  Shale sample application, the "Edit Profile" dialog has a "fullName"
field that is bound
  to a property of the local state object like this:

    <h:inputText id="fullName" value="#{dialog.data.fullName}"/>

  where "dialog" is the session scoped bean containing the state of the
dialog
  computation, and "data" is the general property a dialog can use to
store state
  specific to this dialog.  The state object will be thrown away for
you when the
  dialog completes -- essentially creating a "transaction scope" even though
no
  such thing is (yet) supported by the Servlet API.

* (Recently added) it is possible to define transitions that are
global to an entire
  dialog, rather than having to explicitly define them all inside a
state definition.
  This is exactly analogous to the way that Struts allows you to define
global
  <forward> elements (for the entire application) that can get overridden on
a
  per-action basis by a local <forward> element.

The idea of configuring dialogs and using these facilities works out
quite well ("well, duh" says anyone already familiar with SWF :-).  It
also turned out to be incredibly simple to implement -- one of the JSF
extension points is the NavigationHandler API, which the framework
invokes after the application action returns.  It is used to drive
navigation to another page (or back to the same page, if the logical
outcome is null).  The key method signature is:

    public void handeNavigation(FacesContext context, String
fromAction, String outcome);

where "context" is an encapsulation of the state of the current
request, "fromAction" lets you distinguish between submit buttons
(that might return the same outcome) on the same form, and "outcome"
is the logical outcome that is returned by the action method.

By default, JSF supplies a mechanism that analyzes a set of navigation
rules (defined in a faces-config.xml file) to choose the next view
(typically a JSP page, but that's by no means the only option) to be
rendered.  However, this is an extension point where a framework can
provide value added facilities, or delegate to the standard machinery
if it wants to.

As currently implemented in Shale, the custom NavigationHandler
provides the following facilities:

* When no dialog is being executed, delegate to the standard
  JSF NavigationHandler implementation (so that everything the
  developer knows about JSF navigation happens as expected).

* A dialog named "xxx" is entered when an action returns a logical
  outcome of "dialog:xxx".  This approach required no change to any
  JSF (or JSF-called) APIs -- it's just a specialized interpretation of
  the logical outcome string.

* Once a dialog is entered, state transitions are managed by the custom
  NavigationHandler implementation
(org.apache.shale.dialog.faces.DialogNavigationHandler)
  in a manner very similar to what a SWF Controller does.  This includes
  the ability to nest dialogs (just like SWF can nest flows).

The end result is an environment with some very important benefits
resulting:

* Outside of the dialogs world, standard JSF things work in the usual way.

* Dialogs can reuse actions and view states (including those that are also
  accessed directly via standard JSF facilities), because the interpretation
of
  the logical outcome is specialized per dialog.

* As with SWF, the configuration of a dialog (or a flow) is very much
amenable
  to tool-aided support like graphical drag-n-drop development of the
overall flow --
  as well as for more formal UML-based tool support.

* Because of the other capabilities provided by Shale, an application
will typically
  need fewer "setup" action states (because the prerender() method of a
  ViewController can take many of these responsibilities) and less work in
  what is typically a "bindAndValidate" action in Spring (because JSF has
its
  own support for validation processing that preceeds such a state).  But
these
  are just icing on the cake -- the key values of having managed dialogs are
  independent of Shale.


PROPOSED SWF-JSF INTEGRATION REQUIREMENTS

Given what I've learned from the above investigations, then, I'd like
to propose the following as requirements to be met by an integration
between SWF and JSF:

* When a flow is *not* being exected, all the standard JSF navigation
capabilities
  will work as expected.

* Execution of a JSF action method can cause a SWF flow to be entered, by
  returning a suitably encoded logical outcome (perhaps "flow:xxx" or
"swf:xxx" to
  invoke a flow named "xxx").  In addition, other standard approaches
to entering
  a flow will also work, of course.

* Zero or more flows may reuse the same JSF pages (and backing beans).  This
  implies that the flow management facility will take over the
interpretation of logical
  outcomes from standard JSF action methods, which would otherwise drive the
  standard navigation facilities of JSF.

* There should be a mechanism to push a local state object onto a stack, and
  have it popped off on dialog completion (as Shale does) so that
applications do
  not have to worry about it.  This is not mission critical (and
indeed there might be
  facilities for this already that I haven't discovered yet :-), but
it is very important
  to usability.

* JSF applications using SWF must be able to leverage all of the
sophisticated
  transition management capabilities that SWF supports (as opposed to the
simple
  deterministic model that Shale currently provides).

* When executing a flow, a JSF view state will cause the corresponding JSF
view
   to be rendered, *and* the flow will be suspended until the
subsequent JSF form
  submit occurs.  The logical outcome from the action method that is invoked
for
  the appropriate submit button will be used to drive the next transition.

    - IMPLICATION:  If JSF validation failures occur, the current page will
      be redisplayed without ever invoking the application action
method; implying
      that the current state will remain the same.  This is typically
the desired result,
      but requires no explicit transition management in a JSF-based
application.

* While executing a flow, non-JSF view states should be supported as well
  (this probably comes out of the box, but it needs to be called out).


PROPOSED IMPLEMENTATION APPROACH:

Here's where I really need some help from you guys :-).

It seems that all of the above requirements can be met, in a manner
fairly similar to what I did with Shale's dialogs, by implementing a
custom JSF NavigationHandler with the following features:

* When not currently executing a flow, standard JSF navigation is performed.

* When a logical outcome of the form "flow:xxx" is handed to the
handleNavigation()
   method, the flow named "xxx" is invoked at its start state.

* While a flow is invoking action and subflow states, the usual SWF
processing
  will occur.

* When a flow invokes a view state for a non-JSF page, the usual SWF
processing
  will occur.

* When a flow invokes a view state for a JSF page, the appropriate JSF
incantations
  to create the corresponding view, and render it, will be invoked. 
Further, the state
  of this flow will be suspended until JSF processes a subsequent form
submit, and
  invokes an application action that returns a logical outcome.  This
outcome will be
  the one used to drive a transition from the current view state to
some other state
  in the current flow (or exiting the flow, if this is also an end state).

* I don't see anything like this in the current APIs (but that doesn't
mean it doesn't
  exist :-), but it would be very useful to be able to push and pop
the current model
  data for a flow in a manner similar to what Shale does.  In
particular, this facilitates
  the use of JSF value binding expressions that have a constant
content regardless
  of nested flow execution.

* The implementation should be packaged in a JAR file that contains a
  "META-INF/faces-config.xml" resource that automatically configures
the integration
  with JSF, with no required changes to web.xml (I can help you
accomplish the same
  for the existing JSF managed bean integration as well).

Does this sound compatible with what you guys have had in mind for SWF?

Craig McClanahan


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r 
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer