springframework-developer — Spring Framework developers list

RE: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

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

Yes, so a HttpSessionFlowExecutionStorage would use the HttpSession, a
HttpRequestFlowExecutionStorage would use the request, for example.  The
latter would also have to know how to reconstruct the FlowExecution soley
from the request parameters, while the former would just pull an existing
instance from the HttpSession given the flowExecutionId in the input Event.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Seth Ladd
Sent: Thursday, March 31, 2005 7:56 PM
To: spr...@li...
Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
Feedback needed

On Thu, 31 Mar 2005 19:46:42 -0500, Keith Donald <ke...@in...>
wrote:
> Seth,
> 
> Excellent idea.
> 
> If we extract an interface from the HttpServletExecutionManager, we get
> something like:
> 
> public interface FlowExecutionStorage {
>     public FlowExecution loadFrom(Event inputEvent);
>     public void saveOrUpdate(FlowExecution flowExecution);
>     public void remove(FlowExecution flowExecution);
> }
> 
> Or something like that.  Erwin what do you think? Need to think about it
> more.  I imagine here the FlowExecutionStack would have to be
reconstructed
> from the Event parameters, for example: http request parameters, in an
http
> servlet environment.  It also has to be rehydrated with services on
> deserialization as well, including the FlowLocator and its
> FlowExecutionListenerList.


Keith,

Just so I'm clear... this isn't to replace the concept and purpose of
the HttpSession?  This is just to provide a way to get the state info
of the flow into the request to avoid the need for session creation?

Thanks!
Seth


-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

[Seth L. <set...@gm...>]

On Thu, 31 Mar 2005 19:46:42 -0500, Keith Donald <ke...@in...> wrote:
> Seth,
> 
> Excellent idea.
> 
> If we extract an interface from the HttpServletExecutionManager, we get
> something like:
> 
> public interface FlowExecutionStorage {
>     public FlowExecution loadFrom(Event inputEvent);
>     public void saveOrUpdate(FlowExecution flowExecution);
>     public void remove(FlowExecution flowExecution);
> }
> 
> Or something like that.  Erwin what do you think? Need to think about it
> more.  I imagine here the FlowExecutionStack would have to be reconstructed
> from the Event parameters, for example: http request parameters, in an http
> servlet environment.  It also has to be rehydrated with services on
> deserialization as well, including the FlowLocator and its
> FlowExecutionListenerList.


Keith,

Just so I'm clear... this isn't to replace the concept and purpose of
the HttpSession?  This is just to provide a way to get the state info
of the flow into the request to avoid the need for session creation?

Thanks!
Seth

RE: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

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

Seth,

Excellent idea.

If we extract an interface from the HttpServletExecutionManager, we get
something like:

public interface FlowExecutionStorage {
    public FlowExecution loadFrom(Event inputEvent);
    public void saveOrUpdate(FlowExecution flowExecution);
    public void remove(FlowExecution flowExecution);
}

Or something like that.  Erwin what do you think? Need to think about it
more.  I imagine here the FlowExecutionStack would have to be reconstructed
from the Event parameters, for example: http request parameters, in an http
servlet environment.  It also has to be rehydrated with services on
deserialization as well, including the FlowLocator and its
FlowExecutionListenerList.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Seth Ladd
Sent: Thursday, March 31, 2005 6:21 PM
To: spr...@li...
Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
Feedback needed

On Thu, 31 Mar 2005 17:49:24 -0500, Keith Donald <ke...@in...>
wrote:
> Just thinking out loud here, but no, I don't think this would be too
> difficult to implement.  There is potentially lot to serialize out on each
> request, though, particularly if you a flow execution that has spawned
many
> nested subflows.
> 
> Methinks we could have custom tag that serializes the FlowExecutionStack
on
> each request.  This would include serializing:
> - The ID of the flow execution (randomly generated guid)
> - The stack of IDs of all spawned flows, the top being the active flow and
> the rest any suspended parent flows (if the active flow is a subflow)
> - For each flow in the stack, everything in 'flow scope'.

Keith,

Sounds like there might be two Strategies here for storing the
FlowExecutionStack: HttpSession Strategy and HttpRequest Strategy. 
The developer can then choose the strategy for their needs, as there
are good use cases for not requiring a session.

Seth


-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

[Seth L. <set...@gm...>]

On Thu, 31 Mar 2005 17:49:24 -0500, Keith Donald <ke...@in...> wrote:
> Just thinking out loud here, but no, I don't think this would be too
> difficult to implement.  There is potentially lot to serialize out on each
> request, though, particularly if you a flow execution that has spawned many
> nested subflows.
> 
> Methinks we could have custom tag that serializes the FlowExecutionStack on
> each request.  This would include serializing:
> - The ID of the flow execution (randomly generated guid)
> - The stack of IDs of all spawned flows, the top being the active flow and
> the rest any suspended parent flows (if the active flow is a subflow)
> - For each flow in the stack, everything in 'flow scope'.

Keith,

Sounds like there might be two Strategies here for storing the
FlowExecutionStack: HttpSession Strategy and HttpRequest Strategy. 
The developer can then choose the strategy for their needs, as there
are good use cases for not requiring a session.

Seth

Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

[Seth L. <set...@gm...>]

On Thu, 31 Mar 2005 21:17:02 +0100, Rob Harrop <ro...@ca...> wrote:
> I see no problem in implictly creating a session - although I am
> concerned about the impact of this on clustered applications. Can the
> session implementation be factored out so that users can implement their
> own session storage?

Hi Rob,

One possible way here is to write your own impl of HttpSession and
replace the builtin impl using a Filter.  You can then perform
whatever custom session storage you need.

Seth

RE: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

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

Just thinking out loud here, but no, I don't think this would be too
difficult to implement.  There is potentially lot to serialize out on each
request, though, particularly if you a flow execution that has spawned many
nested subflows.

Methinks we could have custom tag that serializes the FlowExecutionStack on
each request.  This would include serializing:
- The ID of the flow execution (randomly generated guid)
- The stack of IDs of all spawned flows, the top being the active flow and
the rest any suspended parent flows (if the active flow is a subflow)
- For each flow in the stack, everything in 'flow scope'.

This does introduce the issue of having to convert from string
representations of objects in flow scope on each request, possibly applying
automatic type conversion from attribute metadata (e.g from string ->
number).  Do you know how this issue is handled in ASP.NET and JSF?

Currently FlowExecution storage responsibility is externalized from the core
web.flow system -- the FlowExecutionStack, the central object for starting
and manipulating a single client instance of a top-level flow, is a safely
serializable memento.  The HttpServletFlowExecutionManager, by default, uses
HTTP session storage, but the get(..), save(..) and remove(...) methods that
accomplish this could be overridden to serialize to some other place like a
database.

A custom HttpServletFlowExecutionManager subclass would likely need to be
written to accomplish deserializing flow state in a hidden form back to a
fully constructed FlowExecutionStack on each request.  One issue is whether
it makes sense to refactor this class given that need, and if so how.

Keith
 
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Alef Arendsen
Sent: Thursday, March 31, 2005 4:44 PM
To: spr...@li...
Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
Feedback needed

It's what ASP.NET (and I think some JSF implementations) does as well - 
serialization of the state in a hidden input field. I don't think it'd 
be that difficult to implement a custom tag that does this, wouldn't 
it?

rgds,
Alef

On Mar 31, 2005, at 10:30 PM, Rob Harrop wrote:

> I see no problem in implictly creating a session - although I am 
> concerned about the impact of this on clustered applications. Can the 
> session implementation be factored out so that users can implement 
> their own session storage?
>
> Rob
>
> Erwin Vervaet wrote:
>
>> The Spring Web Flow (SWF) FlowController forces the "requireSession" 
>> property it inherits from AbstractController to "true". This is 
>> logical since the webflow system needs to store flow execution state 
>> in the HTTP session.
>>
>> So far so good. However, since the controller now requires an 
>> existing session, the user/developer is responsible for creating that 
>> session before a flow is started. This is typically not a problem in 
>> real-life applications since those carefully manage session creation 
>> and invalidation.
>>
>> Still, we are wondering whether it is a good idea to implicitly 
>> create sessions (usually using request.getSession()) in a controller, 
>> or should this be left as a responsability of the application 
>> developer? Note that AbstractWizardFormController and 
>> AbstractFormController implicitly create sessions.
>>
>> Erwin Vervaet
>> erw...@er...
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by Demarc:
>> A global provider of Threat Management Solutions.
>> Download our HomeAdmin security software for free today!
>> http://www.demarc.com/info/Sentarus/hamr30
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>



-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

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

Indeed - I am actually doing this with a client at the moment. They have 
two separate geographic locations and a small amount of state to 
maintain, so we are going to encode it in hidden fields.

Rob

Alef Arendsen wrote:

> It's what ASP.NET (and I think some JSF implementations) does as well 
> - serialization of the state in a hidden input field. I don't think 
> it'd be that difficult to implement a custom tag that does this, 
> wouldn't it?
>
> rgds,
> Alef
>
> On Mar 31, 2005, at 10:30 PM, Rob Harrop wrote:
>
>> I see no problem in implictly creating a session - although I am 
>> concerned about the impact of this on clustered applications. Can the 
>> session implementation be factored out so that users can implement 
>> their own session storage?
>>
>> Rob
>>
>> Erwin Vervaet wrote:
>>
>>> The Spring Web Flow (SWF) FlowController forces the "requireSession" 
>>> property it inherits from AbstractController to "true". This is 
>>> logical since the webflow system needs to store flow execution state 
>>> in the HTTP session.
>>>
>>> So far so good. However, since the controller now requires an 
>>> existing session, the user/developer is responsible for creating 
>>> that session before a flow is started. This is typically not a 
>>> problem in real-life applications since those carefully manage 
>>> session creation and invalidation.
>>>
>>> Still, we are wondering whether it is a good idea to implicitly 
>>> create sessions (usually using request.getSession()) in a 
>>> controller, or should this be left as a responsability of the 
>>> application developer? Note that AbstractWizardFormController and 
>>> AbstractFormController implicitly create sessions.
>>>
>>> Erwin Vervaet
>>> erw...@er...
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by Demarc:
>>> A global provider of Threat Management Solutions.
>>> Download our HomeAdmin security software for free today!
>>> http://www.demarc.com/info/Sentarus/hamr30
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by Demarc:
>> A global provider of Threat Management Solutions.
>> Download our HomeAdmin security software for free today!
>> http://www.demarc.com/info/Sentarus/hamr30
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

Re: [Springframework-developer] Changes to build.xml to run autobuilds build on 1.5 as well

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

Ok, got it!

I'll add the 1.4 building as a separate build then (as I said before,=20
can't do it in one run because of cruisecontrol limitations).

rgds,
alef

On Mar 31, 2005, at 7:30 PM, Juergen Hoeller wrote:

> AFAIK, when building on JDK 1.5, you're always compiling agains the=20
> 1.5 version of the standard libraries. We would get most value out of=20=

> an auto-build on 1.4 that actually compiles against the 1.4 libraries,=20=

> to make sure that we didn't accentally use 1.5-only methods somewhere.
> =A0
> I do compile on 1.4 before each release anyway, to check that=20
> everything relevant still compiles there. Having this in the=20
> auto-builds would allow us to catch any issues earlier, though.
> =A0
> Juergen
> =A0
> =A0
> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]On=20
> Behalf Of Alef Arendsen
> Sent: Thursday, March 31, 2005 12:03 AM
> To: spr...@li...;=20
> spr...@li...
> Subject: RE: [Springframework-developer] Changes to build.xml to run=20=

> autobuilds build on 1.5 as well
>
>
> You're right, but I'll be adding support for running the unit tests on=20=

> 1.4 as well... I was first thinking about adding a simple master build=20=

> script that executes the two builds (1.4 and 1.5) but the problem here=20=

> is that the 'ant' task does not support forking of a new JVM and doing=20=

> an 'exec' is not an option, since I want to preserve the log files.=20
> JUnit does support the fork (we're already doing it) and you can also=20=

> specify a JVM to use.
>
> About building (compiling), I thought the behavior when building on=20
> 1.5 in combination with adding the compatibility flag would be the=20
> same as with building on 1.4, wouldn't it?
>
> Alef
>
>
> -----Original Message-----
> From: spr...@li... on behalf=20=

> of Juergen Hoeller
> Sent: Wed 3/30/2005 8:15 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Changes to build.xml to run=20=

> autobuilds build on 1.5 as well
>
> Well, I don't object to such a property in general. But such a=20
> property only
> makes sense if you intend to build the 1.4 version on JDK 1.5: I don't=20=

> think
> there's much point in that; building the 1.5 version only would be
> sufficient then.
>
> The capability of our build script to build on 1.4 is really just=20
> meant as a
> fallback for users that want to do custom builds on their 1.4 JDK. The=20=

> only
> value we could add to the auto-builds is to check that building the =
1.4
> version actually works *on JDK 1.4*, which we can't check by building=20=

> on JDK
> 1.5...
>
> Juergen
>
>
> =A0 -----Original Message-----
> =A0 From: spr...@li...
> [mailto:spr...@li...]On=20
> Behalf Of
> Alef Arendsen
> =A0 Sent: Wednesday, March 30, 2005 4:32 PM
> =A0 To: spr...@li...
> =A0 Subject: [Springframework-developer] Changes to build.xml to run
> autobuilds build on 1.5 as well
>
>
> =A0 If nobody objects, I'll be modifying the build file to include an=20=

> extra
> property that indicates whether or not you want to build on 1.5. I=20
> want to
> have the autobuild build for both 1.5 and 1.4 but I can't get this to=20=

> work
> while maintaining the build numbers. To in addition to detecting the=20=

> Java
> version automatically, there will be a property you can specify when=20=

> issuing
> an Ant command.
>
> =A0 regards,
> =A0 Alef
>

Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

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

It's what ASP.NET (and I think some JSF implementations) does as well - 
serialization of the state in a hidden input field. I don't think it'd 
be that difficult to implement a custom tag that does this, wouldn't 
it?

rgds,
Alef

On Mar 31, 2005, at 10:30 PM, Rob Harrop wrote:

> I see no problem in implictly creating a session - although I am 
> concerned about the impact of this on clustered applications. Can the 
> session implementation be factored out so that users can implement 
> their own session storage?
>
> Rob
>
> Erwin Vervaet wrote:
>
>> The Spring Web Flow (SWF) FlowController forces the "requireSession" 
>> property it inherits from AbstractController to "true". This is 
>> logical since the webflow system needs to store flow execution state 
>> in the HTTP session.
>>
>> So far so good. However, since the controller now requires an 
>> existing session, the user/developer is responsible for creating that 
>> session before a flow is started. This is typically not a problem in 
>> real-life applications since those carefully manage session creation 
>> and invalidation.
>>
>> Still, we are wondering whether it is a good idea to implicitly 
>> create sessions (usually using request.getSession()) in a controller, 
>> or should this be left as a responsability of the application 
>> developer? Note that AbstractWizardFormController and 
>> AbstractFormController implicitly create sessions.
>>
>> Erwin Vervaet
>> erw...@er...
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by Demarc:
>> A global provider of Threat Management Solutions.
>> Download our HomeAdmin security software for free today!
>> http://www.demarc.com/info/Sentarus/hamr30
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

[James E. <jam...@gm...>]

I was actually digging through the code earlier and debating the same
thing.  My first instinct was that it should create one for me if it
is required anyway.  I was thinking it would make sense to add a
boolean 'createSessionIfNecessary' field on the
org.springframework.web.servlet.support.WebContentGenerator.  If true,
the session will be created, otherwise an exception will be thrown as
it is now.

The only downside I could think of was when the session times-out
while mid-flow (user waits too long) and data from the previous steps
in the flow are not present (and the next steps are assuming the data
is present).  I'm not sure what problems this could lead to...it would
certainly need to be tested.  One could argue though that if you have
security filters in place, you would'nt get that far anyway...and with
acegi this is probably true.  However with websphere 5.1, the user
authentication is not (or doesn't appear to be) tied to the session
(see below for explaination).  I wouldn't say this is reason to avoid
auto-creating the session...we just need to be aware of the possible
side-effects.

I haven't given Web Flow the full looking over yet so pardon me if
this is a rediculous question, but is there anyway it can support
flows without session (in-addition-to not instead-of)?  Perhaps by
passing the 'current-state' along with the request...and not allowing
flow-scoped attributes in these cases?  I imagine situations where it
would be nice to define flows for visiting users...and not want to
have a session created for all visitors.



When using container managed security in WAS5.1, IF the 'logout'
action simply invalidates the session, webshpere still thinks the user
is authenticated (they have a magic ibm_security_logout uri that must
be hit to clear the user authentication).  I never tested what happens
to the authenication info when a session-timeout occurs...and I don't
have access to a 5.1 machine now...but if it does not become
invalidated when the session does, then websphere would happily say:
"hey, you're authenticated, come on in" and then the session will be
created (empty) for the mid-flow request.  This little change (didn't
happen in 5.0..only 5.1) caused some grief on my last project.

James


On Thu, 31 Mar 2005 21:36:32 +0200, Erwin Vervaet
<erw...@er...> wrote:
> The Spring Web Flow (SWF) FlowController forces the "requireSession"
> property it inherits from AbstractController to "true". This is logical
> since the webflow system needs to store flow execution state in the HTTP
> session.
> 
> So far so good. However, since the controller now requires an existing
> session, the user/developer is responsible for creating that session before
> a flow is started. This is typically not a problem in real-life applications
> since those carefully manage session creation and invalidation.
> 
> Still, we are wondering whether it is a good idea to implicitly create
> sessions (usually using request.getSession()) in a controller, or should
> this be left as a responsability of the application developer? Note that
> AbstractWizardFormController and AbstractFormController implicitly create
> sessions.
> 
> Erwin Vervaet
> erw...@er...
> 
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

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

I see no problem in implictly creating a session - although I am 
concerned about the impact of this on clustered applications. Can the 
session implementation be factored out so that users can implement their 
own session storage?

Rob

Erwin Vervaet wrote:

> The Spring Web Flow (SWF) FlowController forces the "requireSession" 
> property it inherits from AbstractController to "true". This is 
> logical since the webflow system needs to store flow execution state 
> in the HTTP session.
>
> So far so good. However, since the controller now requires an existing 
> session, the user/developer is responsible for creating that session 
> before a flow is started. This is typically not a problem in real-life 
> applications since those carefully manage session creation and 
> invalidation.
>
> Still, we are wondering whether it is a good idea to implicitly create 
> sessions (usually using request.getSession()) in a controller, or 
> should this be left as a responsability of the application developer? 
> Note that AbstractWizardFormController and AbstractFormController 
> implicitly create sessions.
>
> Erwin Vervaet
> erw...@er...
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

[Springframework-developer] XSLTFactoryBean contribution

[Archie C. <ar...@de...>]

We've been using Spring for an application (it works great) and have
written some classes which may be more generally useful. I've attached
a few here for review; we'd be happy to contribute them to Spring if
there's interest.

They may need some tweaks (the copyright and package names at least)
which are no problem, just let me know.

This particular stuff arose from a need to perform XSLT transformations
within an application context at startup time. You use it like this:

     <bean id="initScriptResource"
       class="com.awarix.spring.beans.factory.XSLTFactoryBean">
         <property name="input">
             <value>classpath:com/awarix/reflink/initscr.xml</value>
         </property>
         <property name="transform">
             <value>classpath:com/awarix/reflink/initscr.xsl</value>
         </property>
         <property name="parameters">
             <map>
                 <entry key="param1"><value>42</value></entry>
             </map>
         </property>
     </bean>

Cheers,
-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com

[Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

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

The Spring Web Flow (SWF) FlowController forces the "requireSession" 
property it inherits from AbstractController to "true". This is logical 
since the webflow system needs to store flow execution state in the HTTP 
session.

So far so good. However, since the controller now requires an existing 
session, the user/developer is responsible for creating that session before 
a flow is started. This is typically not a problem in real-life applications 
since those carefully manage session creation and invalidation.

Still, we are wondering whether it is a good idea to implicitly create 
sessions (usually using request.getSession()) in a controller, or should 
this be left as a responsability of the application developer? Note that 
AbstractWizardFormController and AbstractFormController implicitly create 
sessions.

Erwin Vervaet
erw...@er... 

Re: [Springframework-developer] Building/running 1.2RC1 on JDK 1.4.2

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

We ship rowset.jar in the lib/j2ee directory, which should include the
RowSet API as well as Sun's RowSet implementations. Yes, those are included
in JDK 1.5, but they should be taken from rowset.jar if compiling on JDK
1.4...

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Joseph Wortmann
Sent: Thursday, March 31, 2005 7:37 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Building/running 1.2RC1 on JDK
1.4.2


Juergen,

I work w/ Archie, and he asked me to respond.  After reading your message
below, I did some further investigation.  The problem is occurring with the
javax.sql.rowset package, which I thought was only part of 1.5.  I have
found another download from java.sun.com (the JDBC Rowset package) that
appears to have the classes that spring is using.  Is this package from sun
the one you are using to obtain the rowset implementation?

Joe Wortmann

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Juergen Hoeller
> Sent: Thursday, March 31, 2005 11:13 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Building/running 1.2RC1 on JDK
> 1.4.2
>
> Spring 1.2 RC1 is supposed to be buildable on JDK 1.5 and JDK 1.4.2, and
> supposed to run on JDK >= 1.3. I've verified that it does all of those
> before the release, so I wonder what failed in your case... Which JDBC
> classes were missing, exactly?
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Archie Cobbs
> Sent: Thursday, March 31, 2005 2:06 AM
> To: spr...@li...
> Cc: 'Joe Wortmann'
> Subject: [Springframework-developer] Building/running 1.2RC1 on JDK
> 1.4.2
>
>
> Hi,
>
> We're trying to build Spring on a JDK 1.4.2 system, and the build
> is failing due to some missing JDBC classes.
>
> Is 1.2RC1 supposed to build on 1.4? Is it supposed to run on 1.4?
>
> Thanks for any insights.
>
> Cheers,
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Building/running 1.2RC1 on JDK 1.4.2

[Joseph W. <jwo...@aw...>]

Juergen,

I work w/ Archie, and he asked me to respond.  After reading your message
below, I did some further investigation.  The problem is occurring with the
javax.sql.rowset package, which I thought was only part of 1.5.  I have
found another download from java.sun.com (the JDBC Rowset package) that
appears to have the classes that spring is using.  Is this package from sun
the one you are using to obtain the rowset implementation?

Joe Wortmann

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Juergen Hoeller
> Sent: Thursday, March 31, 2005 11:13 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Building/running 1.2RC1 on JDK
> 1.4.2
> 
> Spring 1.2 RC1 is supposed to be buildable on JDK 1.5 and JDK 1.4.2, and
> supposed to run on JDK >= 1.3. I've verified that it does all of those
> before the release, so I wonder what failed in your case... Which JDBC
> classes were missing, exactly?
> 
> Juergen
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Archie Cobbs
> Sent: Thursday, March 31, 2005 2:06 AM
> To: spr...@li...
> Cc: 'Joe Wortmann'
> Subject: [Springframework-developer] Building/running 1.2RC1 on JDK
> 1.4.2
> 
> 
> Hi,
> 
> We're trying to build Spring on a JDK 1.4.2 system, and the build
> is failing due to some missing JDBC classes.
> 
> Is 1.2RC1 supposed to build on 1.4? Is it supposed to run on 1.4?
> 
> Thanks for any insights.
> 
> Cheers,
> -Archie
> 
> __________________________________________________________________________
> Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Changes to build.xml to run autobuilds build on 1.5 as well

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

RE: [Springframework-developer] Changes to build.xml to run autobuilds build
on 1.5 as wellAFAIK, when building on JDK 1.5, you're always compiling
agains the 1.5 version of the standard libraries. We would get most value
out of an auto-build on 1.4 that actually compiles against the 1.4
libraries, to make sure that we didn't accentally use 1.5-only methods
somewhere.

I do compile on 1.4 before each release anyway, to check that everything
relevant still compiles there. Having this in the auto-builds would allow us
to catch any issues earlier, though.

Juergen


  -----Original Message-----
  From: spr...@li...
[mailto:spr...@li...]On Behalf Of
Alef Arendsen
  Sent: Thursday, March 31, 2005 12:03 AM
  To: spr...@li...;
spr...@li...
  Subject: RE: [Springframework-developer] Changes to build.xml to run
autobuilds build on 1.5 as well


  You're right, but I'll be adding support for running the unit tests on 1.4
as well... I was first thinking about adding a simple master build script
that executes the two builds (1.4 and 1.5) but the problem here is that the
'ant' task does not support forking of a new JVM and doing an 'exec' is not
an option, since I want to preserve the log files. JUnit does support the
fork (we're already doing it) and you can also specify a JVM to use.

  About building (compiling), I thought the behavior when building on 1.5 in
combination with adding the compatibility flag would be the same as with
building on 1.4, wouldn't it?

  Alef


  -----Original Message-----
  From: spr...@li... on behalf of
Juergen Hoeller
  Sent: Wed 3/30/2005 8:15 PM
  To: spr...@li...
  Subject: Re: [Springframework-developer] Changes to build.xml to run
autobuilds build on 1.5 as well

  Well, I don't object to such a property in general. But such a property
only
  makes sense if you intend to build the 1.4 version on JDK 1.5: I don't
think
  there's much point in that; building the 1.5 version only would be
  sufficient then.

  The capability of our build script to build on 1.4 is really just meant as
a
  fallback for users that want to do custom builds on their 1.4 JDK. The
only
  value we could add to the auto-builds is to check that building the 1.4
  version actually works *on JDK 1.4*, which we can't check by building on
JDK
  1.5...

  Juergen


    -----Original Message-----
    From: spr...@li...
  [mailto:spr...@li...]On Behalf Of
  Alef Arendsen
    Sent: Wednesday, March 30, 2005 4:32 PM
    To: spr...@li...
    Subject: [Springframework-developer] Changes to build.xml to run
  autobuilds build on 1.5 as well


    If nobody objects, I'll be modifying the build file to include an extra
  property that indicates whether or not you want to build on 1.5. I want to
  have the autobuild build for both 1.5 and 1.4 but I can't get this to work
  while maintaining the build numbers. To in addition to detecting the Java
  version automatically, there will be a property you can specify when
issuing
  an Ant command.

    regards,
    Alef

Re: [Springframework-developer] Building/running 1.2RC1 on JDK 1.4.2

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

Spring 1.2 RC1 is supposed to be buildable on JDK 1.5 and JDK 1.4.2, and
supposed to run on JDK >= 1.3. I've verified that it does all of those
before the release, so I wonder what failed in your case... Which JDBC
classes were missing, exactly?

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Archie Cobbs
Sent: Thursday, March 31, 2005 2:06 AM
To: spr...@li...
Cc: 'Joe Wortmann'
Subject: [Springframework-developer] Building/running 1.2RC1 on JDK
1.4.2


Hi,

We're trying to build Spring on a JDK 1.4.2 system, and the build
is failing due to some missing JDBC classes.

Is 1.2RC1 supposed to build on 1.4? Is it supposed to run on 1.4?

Thanks for any insights.

Cheers,
-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com


-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Changes to build.xml to run autobuilds build on 1.5 as well

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

Yeah - but only one of my addresses :-)

 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Alef Arendsen
Sent: 31 March 2005 17:39
To: spr...@li...
Subject: RE: [Springframework-developer] Changes to build.xml to run
autobuilds build on 1.5 as well

 

Anybody else having experiencing major delays with the mailinglist???

 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Alef Arendsen
Sent: Thursday, March 31, 2005 5:46 PM
To: spr...@li...;
spr...@li...
Subject: RE: [Springframework-developer] Changes to build.xml to run
autobuilds build on 1.5 as well

You're right, but I'll be adding support for running the unit tests on 1.4
as well... I was first thinking about adding a simple master build script
that executes the two builds (1.4 and 1.5) but the problem here is that the
'ant' task does not support forking of a new JVM and doing an 'exec' is not
an option, since I want to preserve the log files. JUnit does support the
fork (we're already doing it) and you can also specify a JVM to use.

About building (compiling), I thought the behavior when building on 1.5 in
combination with adding the compatibility flag would be the same as with
building on 1.4, wouldn't it?

Alef


-----Original Message-----
From: spr...@li... on behalf of
Juergen Hoeller
Sent: Wed 3/30/2005 8:15 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Changes to build.xml to run
autobuilds build on 1.5 as well

Well, I don't object to such a property in general. But such a property only
makes sense if you intend to build the 1.4 version on JDK 1.5: I don't think
there's much point in that; building the 1.5 version only would be
sufficient then.

The capability of our build script to build on 1.4 is really just meant as a
fallback for users that want to do custom builds on their 1.4 JDK. The only
value we could add to the auto-builds is to check that building the 1.4
version actually works *on JDK 1.4*, which we can't check by building on JDK
1.5...

Juergen


  -----Original Message-----
  From: spr...@li...
[mailto:spr...@li...]On Behalf Of
Alef Arendsen
  Sent: Wednesday, March 30, 2005 4:32 PM
  To: spr...@li...
  Subject: [Springframework-developer] Changes to build.xml to run
autobuilds build on 1.5 as well


  If nobody objects, I'll be modifying the build file to include an extra
property that indicates whether or not you want to build on 1.5. I want to
have the autobuild build for both 1.5 and 1.4 but I can't get this to work
while maintaining the build numbers. To in addition to detecting the Java
version automatically, there will be a property you can specify when issuing
an Ant command.

  regards,
  Alef

Re: [Springframework-developer] SleepyCat Berkeley DB Java Edition ORM layer

[Luis T. <lui...@gm...>]

To may knowledge Berkeley is very active, and it night open up Spring
to a new user base.
Please get this links:
http://www.sleepycat.com/solutions/customers.shtml
http://www.sleepycat.com/solutions/opensource.shtml 


Regards, Oscar


On Thu, 31 Mar 2005 11:03:59 -0500, Dmitriy Kopylenko
<dko...@ru...> wrote:
> I'd like to ask - who uses Berkley DB JE? Are there any production
> deployments? Is there a big demand for Spring integration?
> 
> Regards,
> Dmitriy.
> 
> Luis Trigueiros wrote:
> 
> >Dear all,
> >I have wrote some factory beans to integrate Springframework with
> >Berkley DB JE, and I would like to ask you guys if you would want to
> >have as part of your code base.
> >It is 70% done all that it is remains is to write an implementation of
> >org.springframework.transaction.PlatformTransactionManager, which is
> >partly written already based on
> >org.springframework.transaction.support.AbstractPlatformTransactionManager.
> >I understand most of the transaction manager code but since
> >transaction JE transaction API has a different semantics I would like
> >to if some of you guys had a look at it.
> >I think that this could be made as an additional ORM layer.
> >
> >Best regards, Oscar
> >
> >
> >-------------------------------------------------------
> >This SF.net email is sponsored by Demarc:
> >A global provider of Threat Management Solutions.
> >Download our HomeAdmin security software for free today!
> >http://www.demarc.com/info/Sentarus/hamr30
> >_______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
> >https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> 
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

RE: [Springframework-developer] Changes to build.xml to run autobuilds build on 1.5 as well

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

Anybody else having experiencing major delays with the mailinglist???

________________________________

From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Alef Arendsen
Sent: Thursday, March 31, 2005 5:46 PM
To: spr...@li...;
spr...@li...
Subject: RE: [Springframework-developer] Changes to build.xml to run
autobuilds build on 1.5 as well



You're right, but I'll be adding support for running the unit tests on
1.4 as well... I was first thinking about adding a simple master build
script that executes the two builds (1.4 and 1.5) but the problem here
is that the 'ant' task does not support forking of a new JVM and doing
an 'exec' is not an option, since I want to preserve the log files.
JUnit does support the fork (we're already doing it) and you can also
specify a JVM to use.

About building (compiling), I thought the behavior when building on 1.5
in combination with adding the compatibility flag would be the same as
with building on 1.4, wouldn't it?

Alef


-----Original Message-----
From: spr...@li... on behalf of
Juergen Hoeller
Sent: Wed 3/30/2005 8:15 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Changes to build.xml to run
autobuilds build on 1.5 as well

Well, I don't object to such a property in general. But such a property
only
makes sense if you intend to build the 1.4 version on JDK 1.5: I don't
think
there's much point in that; building the 1.5 version only would be
sufficient then.

The capability of our build script to build on 1.4 is really just meant
as a
fallback for users that want to do custom builds on their 1.4 JDK. The
only
value we could add to the auto-builds is to check that building the 1.4
version actually works *on JDK 1.4*, which we can't check by building on
JDK
1.5...

Juergen


  -----Original Message-----
  From: spr...@li...
[mailto:spr...@li...]On Behalf
Of
Alef Arendsen
  Sent: Wednesday, March 30, 2005 4:32 PM
  To: spr...@li...
  Subject: [Springframework-developer] Changes to build.xml to run
autobuilds build on 1.5 as well


  If nobody objects, I'll be modifying the build file to include an
extra
property that indicates whether or not you want to build on 1.5. I want
to
have the autobuild build for both 1.5 and 1.4 but I can't get this to
work
while maintaining the build numbers. To in addition to detecting the
Java
version automatically, there will be a property you can specify when
issuing
an Ant command.

  regards,
  Alef

Re: [Springframework-developer] SleepyCat Berkeley DB Java Edition ORM layer

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

I'd like to ask - who uses Berkley DB JE? Are there any production 
deployments? Is there a big demand for Spring integration?

Regards,
Dmitriy.

Luis Trigueiros wrote:

>Dear all,
>I have wrote some factory beans to integrate Springframework with
>Berkley DB JE, and I would like to ask you guys if you would want to
>have as part of your code base.
>It is 70% done all that it is remains is to write an implementation of
>org.springframework.transaction.PlatformTransactionManager, which is
>partly written already based on
>org.springframework.transaction.support.AbstractPlatformTransactionManager.
>I understand most of the transaction manager code but since
>transaction JE transaction API has a different semantics I would like
>to if some of you guys had a look at it.
>I think that this could be made as an additional ORM layer. 
>
>Best regards, Oscar
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by Demarc:
>A global provider of Threat Management Solutions.
>Download our HomeAdmin security software for free today!
>http://www.demarc.com/info/Sentarus/hamr30
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

Re: [Springframework-developer] Re: Portlet Form Controllers

[William G. T. Jr. <wg...@ru...>]

Juergen Hoeller wrote:
> That sounds like a good plan to me! It would be great to get this going
> ASAP. After all, our timeplan for Spring 1.3 is pretty aggressive, so
> waiting till after 1.2 final might not leave enough time.
> 
> Bill, Dmitriy, anyone volunteering to manage the sandbox code in the
> meantime? :-) This would have to be someone with commit rights, after all,
> and ideally someone already using the Portlet code.

I should be able to get the all the latest patches in next week.

Bill

> 
> First step would be to merge all existing contributions in. Let's assume
> that the Portlet code will become part of Spring 1.3 proper (which is
> likely), and continue to work on it in the sandbox.
> 
> Juergen
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Rainer Schmitz
> Sent: Wednesday, March 30, 2005 11:53 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Re: Portlet Form Controllers
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> While the "official" work on the Portlet support are postponed to Spring
> 1.3 I still would like to have a place for discussions and code
> contributions. At this time the discussion is spread across this list,
> the forum, confluence, and JIRA, which makes it hard to follow.
> 
> As for discussions, I would propose to stick to this list - we *are*
> talking about Spring development, and this way the experienced Spring
> developers may take the opportunity to participate.
> 
> As for code contributios: during the past couple of month several people
> (William, Nick, John, and me) have contributed some code, but after each
> contribution there was a big gap. One reason might be that it's very
> inconvenient to get the up-to-date version of the code (none of the
> changes made it into CVS; you have to fetch the sandbox version and copy
> the content of several zip files from confluence). Without a proper code
> management facility it's pointless to add more contributions.
> 
> I'm undecided wether portlet support should be part of main Spring or a
> sub project, but for the time being it would really help if the portlet
> code would be located at a place where all interested people could find
> the up-to-date version and contribute enhancements. When the official
> work in the Spring 1.3 context begins, this code could be an
> implementation base for any portlet code handled in the traditional way.
> 
> What do you think?
> 
> Rainer
> 
> 
> 
> Juergen Hoeller schrieb:
> 
>>John,
>>
>>Sorry for the late reply. Thanks for volunteering! :-)
>>
>>Let's continue to proceed in the Portlet area once Spring 1.2 is out. Both
>>Spring Web Flows and the Portlet support are currently planned to be
>>cornerstones of Spring 1.3.
>>
>>Regarding commit rights, let's discuss this once 1.2 is out too. We're
>>willing to extend the developer team, but there's a couple of things to be
>>clarified (CLA etc).
>>
>>In the meantime, feel free to create a JIRA issue for your enhancements!
> 
> I'm
> 
>>sure that Dmitriy, Bill and co will be happy to have an early look at
> 
> this.
> 
>>Juergen
>>
>>
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFCSnb7w+xsU7A7UOgRAo39AJ9LlKn1KvEOFzItXO83+oUoUhvMHgCfWoVy
> rv556WE9CYsBzgbrTtkRqLU=
> =qCQl
> -----END PGP SIGNATURE-----
> 
> 
> -------------------------------------------------------
> 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


-- 
William G. Thompson, Jr.
Associate Director for New Technology
Enterprise Systems and Services, Rutgers University
voice: 732 445-5428 | fax: 732 445-5493 | wg...@ru...

[Springframework-developer] SleepyCat Berkeley DB Java Edition ORM layer

[Luis T. <lui...@gm...>]

Dear all,
I have wrote some factory beans to integrate Springframework with
Berkley DB JE, and I would like to ask you guys if you would want to
have as part of your code base.
It is 70% done all that it is remains is to write an implementation of
org.springframework.transaction.PlatformTransactionManager, which is
partly written already based on
org.springframework.transaction.support.AbstractPlatformTransactionManager.
I understand most of the transaction manager code but since
transaction JE transaction API has a different semantics I would like
to if some of you guys had a look at it.
I think that this could be made as an additional ORM layer. 

Best regards, Oscar

Re: [Springframework-developer] webflow additions

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

Hi all,

We have upgraded Spring Web Flow addition for Portlets for use with the 
Spring
1.2 RC1 and Spring Web Flow PR1.

To download it:

http://opensource.atlassian.com/confluence/spring/display/WEBFLOW/Home

Regards,

-- 
J.Enrique Ruiz
Chief Research & Innovation Officer - DiSiD S.L.L. (http://www.disid.com)
Email: er...@di...

Re: [Springframework-developer] Weird freemarker behavior with spring.ftl

[<jo....@us...>]

Darren Davison wrote:

> Jo,
>
> If you can you create a JIRA issue for this (you can attach the patch 
> there)
> I'll take a look at it this week.
>
>

Just did:

http://opensource.atlassian.com/projects/spring/browse/SPR-838

Jo