You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(55) |
Mar
(100) |
Apr
(203) |
May
(330) |
Jun
(190) |
Jul
(302) |
Aug
(323) |
Sep
(197) |
Oct
(245) |
Nov
(490) |
Dec
(330) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(194) |
Feb
(400) |
Mar
(416) |
Apr
(415) |
May
(359) |
Jun
(381) |
Jul
(491) |
Aug
(311) |
Sep
(291) |
Oct
(273) |
Nov
(355) |
Dec
(266) |
| 2005 |
Jan
(306) |
Feb
(303) |
Mar
(520) |
Apr
(346) |
May
(255) |
Jun
(221) |
Jul
(171) |
Aug
(247) |
Sep
(147) |
Oct
(125) |
Nov
(165) |
Dec
(65) |
| 2006 |
Jan
(90) |
Feb
(53) |
Mar
(121) |
Apr
(103) |
May
(113) |
Jun
(103) |
Jul
(104) |
Aug
(67) |
Sep
(78) |
Oct
(82) |
Nov
(78) |
Dec
(70) |
| 2007 |
Jan
(77) |
Feb
(76) |
Mar
(63) |
Apr
(30) |
May
(47) |
Jun
(41) |
Jul
(44) |
Aug
(44) |
Sep
(49) |
Oct
(33) |
Nov
(25) |
Dec
(21) |
| 2008 |
Jan
(45) |
Feb
(13) |
Mar
(15) |
Apr
(12) |
May
(9) |
Jun
(33) |
Jul
(30) |
Aug
(7) |
Sep
(20) |
Oct
(17) |
Nov
(20) |
Dec
(10) |
| 2009 |
Jan
(8) |
Feb
(5) |
Mar
(12) |
Apr
(17) |
May
(19) |
Jun
(97) |
Jul
(77) |
Aug
(33) |
Sep
(24) |
Oct
(41) |
Nov
(16) |
Dec
(32) |
| 2010 |
Jan
(24) |
Feb
(14) |
Mar
(50) |
Apr
(71) |
May
(70) |
Jun
(64) |
Jul
(45) |
Aug
(62) |
Sep
(32) |
Oct
(4) |
Nov
(12) |
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(4) |
Oct
(6) |
Nov
(3) |
Dec
(3) |
| 2012 |
Jan
(4) |
Feb
(8) |
Mar
(6) |
Apr
(10) |
May
(2) |
Jun
(3) |
Jul
(11) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(4) |
Feb
(1) |
Mar
(9) |
Apr
(1) |
May
(8) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(10) |
Dec
(8) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(9) |
Apr
(12) |
May
(2) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(9) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(7) |
Oct
(9) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(7) |
Feb
(5) |
Mar
(5) |
Apr
(5) |
May
(8) |
Jun
(4) |
Jul
(5) |
Aug
(4) |
Sep
(6) |
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2017 |
Jan
(7) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Darren D. <da...@sh...> - 2005-09-27 07:22:46
|
1127805758
FAILED
[junit] Testsuite: org.springframework.core.enums.LabeledEnumTests
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0,371 sec
[junit] Testcase: testEquals took 0,031 sec
[junit] Testcase: testForCodeFound took 0,317 sec
[junit] Testcase: testDoesNotMatchWrongClass took 0,001 sec
[junit] Tests run: 15, Failures: 1, Errors: 0, Time elapsed: 0,525 sec
[junit] Testsuite: org.springframework.core.io.ResourceTests
[junit] Tests run: 15, Failures: 1, Errors: 0, Time elapsed: 0,525 sec
[junit] Testcase: testByteArrayResource took 0,008 sec
[junit] Testcase: testByteArrayResourceWithDescription took 0 sec
[junit] Testcase: testInputStreamResource took 0,007 sec
[junit] Testcase: testInputStreamResourceWithDescription took 0,001 sec
[junit] Testcase: testClassPathResource took 0,023 sec
[junit] Testcase: testClassPathResourceWithClassLoader took 0,012 sec
[junit] Testcase: testClassPathResourceWithClass took 0,012 sec
[junit] Testcase: testFileSystemResource took 0,002 sec
[junit] Testcase: testUrlResource took 0,002 sec
[junit] Testcase: testServletContextResource took 0,262 sec
[junit] Testcase: testClassPathResourceWithRelativePath took 0 sec
[junit] Testcase: testFileSystemResourceWithRelativePath took 0 sec
[junit] Testcase: testUrlResourceWithRelativePath took 0,001 sec
[junit] Testcase: testServletContextResourceWithRelativePath took 0 sec
[junit] Testcase: testNonFileResourceExists took 0,16 sec
[junit] FAILED
[junit] null
[junit] junit.framework.AssertionFailedError
[junit] at org.springframework.core.io.ResourceTests.testNonFileResourceExists(ResourceTests.java:151)
This is an automated mail from one of the SF Compile Farm machines.
The machine name noted in the subject encountered a failure building
or running the Spring test suite. The last few lines of the output
were included for info.
NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.
See http://springframework.sourceforge.net/test/ for further
information.
|
|
From: Trevor B. <tre...@gm...> - 2005-09-26 23:33:26
|
Hi all,
I wanted to draw attention to a behavior in Spring that I was
already aware of, but which bit me unexpectedly in a project I was
called in to help. (it cropped up due to some 'mis-use' of Spring).
I found this with Spring 1.2.3. When I went back to Spring 1.0.2 I
found that it exhibited different behavior, which I consider more
correct. I found the JIRA issue that relates to this change:
http://opensource2.atlassian.com/projects/spring/browse/SPR-174
Let me explain the scenario I encountered.
Spring can call private constructors for beans (since 1.1RC1). Take
this simple Java class:
public class MySingletonBean {
private static MySingletonBean s_instance =3D new MySingletonBean();
private MySingletonBean() {
System.out.println("Creating MySingletonBean");
}
public static MySingletonBean getInstance() {
return s_instance;
}
}
With a spring bean definition like so:
<bean id=3D"MyBean"
class=3D"com.example.MySingletonBean">
</bean>
I find that when I load an ApplicationContext, Spring successfully
calls the private constructor (by calling setAccessible(true) on the
java.lang.Constructor object).
When I think about it, I guess that I would have expected that Spring
would have flagged this usage as an error or at least a warning - e.g.
"No public constructor in class [class com.example.MySingletonBean]".
I came across this feature when I was called in to help out an
application that was having a problem which turned out to be multiple
singletons within a single classloader. A class was defined as a
singleton using the typical pattern (i.e. private constructor, static
getInstance() method), but was also defined in a Spring context using
a bean definiton like so:
<bean id=3D"MyBean"
class=3D"com.example.MySingletonBean">
</bean>
Of course to be correct, the bean definition should have been:
<bean id=3D"MyBean"
class=3D"com.example.MySingletonBean"
factory-method=3D"getInstance">
</bean>
Different places in the application code were accessing the same
object in different ways - some were using Spring, others were calling
getInstance(). Of course, we had two instances of the singleton within
the application - so the code was not behaving correctly.
While the design of this part of the app was not exactly correct/good
practice (should really just be using one mechanism to access the
object) - it still exposed a behavior in Spring that I think may not
be wholly intuitive. I have since reworked this to something I think
is more suitable, removing the singleton pattern implementation and
simply using Spring to wire up the singleton object to all objects
that need it.
With Spring 1.0.2 - we do not have this problem. Spring throws an error:
Exception in thread "main"
org.springframework.beans.factory.BeanDefinitionStoreException: Error
registering bean with name 'MyBean' defined in class path resource
[applicationContext.xml]: Validation of bean definition with name
failed; nested exception is
org.springframework.beans.factory.support.BeanDefinitionValidationException=
:
No public constructor in class [class com.example.MySingletonBean]
I was just curious as to the development team's thoughts on this
issue. I understand there are scenarios where we may want to
instantiate beans that only have private constructors. But it does
open up the possibility for miss-use - as can be seen from my concrete
example above.
Regards,
Trevor
|
|
From: Juergen H. <ju...@in...> - 2005-09-26 08:03:18
|
Hi Darren, From my point of view, it's fine to remove anything that's been deprecated before 1.2 final. This in particular applies to class hierarchies with template methods, where deprecated hooks tend to confuse subclass creators. I've applied an analogous rule on our way from 1.1 to 1.2. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Darren Davison Sent: Monday, September 26, 2005 9:59 AM To: spr...@li... Subject: [Springframework-developer] Deprecated methods Hi all, A while back there was a discussion about deprecated methods. I think we tentatively agreed that methods deprecated prior to the release of 1.2 were candidates for removal in 1.3. The point being obviously not to break apps upgrading from 1.1 to 1.2, but not to have such restrictions on upgrading from 1.1 to 1.3 Is this still the case? I'd like to remove something in AbstractXsltView that was deprecated in 1.2 RC1. Cheers, -- Darren Davison Public Key: 0xDD356B0D |
|
From: Darren D. <da...@da...> - 2005-09-26 07:59:26
|
Hi all, A while back there was a discussion about deprecated methods. I think we tentatively agreed that methods deprecated prior to the release of 1.2 were candidates for removal in 1.3. The point being obviously not to break apps upgrading from 1.1 to 1.2, but not to have such restrictions on upgrading f= rom 1.1 to 1.3 Is this still the case? I'd like to remove something in AbstractXsltView t= hat was deprecated in 1.2 RC1. Cheers, --=20 Darren Davison Public Key: 0xDD356B0D |
|
From: Rob B. <cro...@ya...> - 2005-09-24 02:32:25
|
Hey all,
I was wondering if Spring could be enhanced to support
"conditional configuration" or if there is a way to do
this already that I haven't thought of.
Let's say your app has a property file bean post
processor. Depending upon a setting in the property
file you want to switch between two different
implementations of some interface - Impl1 & Impl2. No
problem, Spring does this easily.
But let's say those two different implementations also
have a number of Spring managed beans injected into
them. So if your using Impl2 then all the Spring
managed beans that are injected into Impl1 aren't
needed.
Is there a way to have spring _not_ instatiate and
configure some beans depending upon a value obtained
from a bean post processor?
If this doesn't already exit perhaps a new attribute
can be added to the bean tag like "load" or
"configure". If load="true" then the bean is loaded.
In this way Impl1 could be keyed to load="${useImpl1}"
and so could all of the Spring managed beans that
would be injected into it. Thus, if useImpl1 was
false Impl1 and all the objects constructed to support
it would never be instantiated.
It would also be preferable for references to bean
post processor values that used in un-instantiated
objects to no longer be necessary. I.E. if Impl1 has
someSetter="${someProperty}" and Impl1 load="false"
then spring should not error if "someProperty" is not
provided.
Thoughts?
Rob
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
|
|
From: Darren D. <da...@sh...> - 2005-09-23 14:18:29
|
1127485098
FAILED
[junit] Testsuite: org.springframework.core.enums.LabeledEnumTests
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0,098 sec
[junit] Testcase: testEquals took 0,05 sec
[junit] Testcase: testForCodeFound took 0,023 sec
[junit] Testcase: testDoesNotMatchWrongClass took 0,001 sec
[junit] Tests run: 15, Failures: 1, Errors: 0, Time elapsed: 0,265 sec
[junit] Testsuite: org.springframework.core.io.ResourceTests
[junit] Tests run: 15, Failures: 1, Errors: 0, Time elapsed: 0,265 sec
[junit] Testcase: testByteArrayResource took 0,006 sec
[junit] Testcase: testByteArrayResourceWithDescription took 0 sec
[junit] Testcase: testInputStreamResource took 0,005 sec
[junit] Testcase: testInputStreamResourceWithDescription took 0 sec
[junit] Testcase: testClassPathResource took 0,016 sec
[junit] Testcase: testClassPathResourceWithClassLoader took 0,013 sec
[junit] Testcase: testClassPathResourceWithClass took 0,012 sec
[junit] Testcase: testFileSystemResource took 0,003 sec
[junit] Testcase: testUrlResource took 0,003 sec
[junit] Testcase: testServletContextResource took 0,059 sec
[junit] Testcase: testClassPathResourceWithRelativePath took 0 sec
[junit] Testcase: testFileSystemResourceWithRelativePath took 0 sec
[junit] Testcase: testUrlResourceWithRelativePath took 0,001 sec
[junit] Testcase: testServletContextResourceWithRelativePath took 0 sec
[junit] Testcase: testNonFileResourceExists took 0,116 sec
[junit] FAILED
[junit] null
[junit] junit.framework.AssertionFailedError
[junit] at org.springframework.core.io.ResourceTests.testNonFileResourceExists(ResourceTests.java:151)
This is an automated mail from one of the SF Compile Farm machines.
The machine name noted in the subject encountered a failure building
or running the Spring test suite. The last few lines of the output
were included for info.
NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.
See http://springframework.sourceforge.net/test/ for further
information.
|
|
From: Darren D. <da...@sh...> - 2005-09-23 09:19:53
|
1127467188
FAILED
[junit] Testsuite: org.springframework.core.enums.LabeledEnumTests
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0,058 sec
[junit] Testcase: testEquals took 0,021 sec
[junit] Testcase: testForCodeFound took 0,02 sec
[junit] Testcase: testDoesNotMatchWrongClass took 0 sec
[junit] Tests run: 15, Failures: 1, Errors: 0, Time elapsed: 0,25 sec
[junit] Testsuite: org.springframework.core.io.ResourceTests
[junit] Tests run: 15, Failures: 1, Errors: 0, Time elapsed: 0,25 sec
[junit] Testcase: testByteArrayResource took 0,009 sec
[junit] Testcase: testByteArrayResourceWithDescription took 0 sec
[junit] Testcase: testInputStreamResource took 0,005 sec
[junit] Testcase: testInputStreamResourceWithDescription took 0,001 sec
[junit] Testcase: testClassPathResource took 0,009 sec
[junit] Testcase: testClassPathResourceWithClassLoader took 0,004 sec
[junit] Testcase: testClassPathResourceWithClass took 0,005 sec
[junit] Testcase: testFileSystemResource took 0,001 sec
[junit] Testcase: testUrlResource took 0,002 sec
[junit] Testcase: testServletContextResource took 0,041 sec
[junit] Testcase: testClassPathResourceWithRelativePath took 0,001 sec
[junit] Testcase: testFileSystemResourceWithRelativePath took 0 sec
[junit] Testcase: testUrlResourceWithRelativePath took 0,001 sec
[junit] Testcase: testServletContextResourceWithRelativePath took 0 sec
[junit] Testcase: testNonFileResourceExists took 0,14 sec
[junit] FAILED
[junit] null
[junit] junit.framework.AssertionFailedError
[junit] at org.springframework.core.io.ResourceTests.testNonFileResourceExists(ResourceTests.java:151)
This is an automated mail from one of the SF Compile Farm machines.
The machine name noted in the subject encountered a failure building
or running the Spring test suite. The last few lines of the output
were included for info.
NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.
See http://springframework.sourceforge.net/test/ for further
information.
|
|
From: Darren D. <da...@sh...> - 2005-09-23 07:22:51
|
1127460168
FAILED
[junit] Testsuite: org.springframework.core.enums.LabeledEnumTests
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0,092 sec
[junit] Testcase: testEquals took 0,035 sec
[junit] Testcase: testForCodeFound took 0,037 sec
[junit] Testcase: testDoesNotMatchWrongClass took 0,001 sec
[junit] Tests run: 15, Failures: 1, Errors: 0, Time elapsed: 0,353 sec
[junit] Testsuite: org.springframework.core.io.ResourceTests
[junit] Tests run: 15, Failures: 1, Errors: 0, Time elapsed: 0,353 sec
[junit] Testcase: testByteArrayResource took 0,014 sec
[junit] Testcase: testByteArrayResourceWithDescription took 0,001 sec
[junit] Testcase: testInputStreamResource took 0,007 sec
[junit] Testcase: testInputStreamResourceWithDescription took 0,001 sec
[junit] Testcase: testClassPathResource took 0,016 sec
[junit] Testcase: testClassPathResourceWithClassLoader took 0,012 sec
[junit] Testcase: testClassPathResourceWithClass took 0,013 sec
[junit] Testcase: testFileSystemResource took 0,003 sec
[junit] Testcase: testUrlResource took 0,003 sec
[junit] Testcase: testServletContextResource took 0,06 sec
[junit] Testcase: testClassPathResourceWithRelativePath took 0 sec
[junit] Testcase: testFileSystemResourceWithRelativePath took 0 sec
[junit] Testcase: testUrlResourceWithRelativePath took 0 sec
[junit] Testcase: testServletContextResourceWithRelativePath took 0,001 sec
[junit] Testcase: testNonFileResourceExists took 0,187 sec
[junit] FAILED
[junit] null
[junit] junit.framework.AssertionFailedError
[junit] at org.springframework.core.io.ResourceTests.testNonFileResourceExists(ResourceTests.java:151)
This is an automated mail from one of the SF Compile Farm machines.
The machine name noted in the subject encountered a failure building
or running the Spring test suite. The last few lines of the output
were included for info.
NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.
See http://springframework.sourceforge.net/test/ for further
information.
|
|
From: Colin S. <col...@ex...> - 2005-09-23 00:55:54
|
My convention when making a branch is to use the same basic name as the release, i.e. R_1-2-5 becomes B_1-2-5 where you then might have a release R_1-2-5-1 coming off it later. But I guess in this case any release is going to be 1.2.6. So I would probably call it branch-1-2. I do like to call branches as branches, since they have to be treated differently than normal tags. Colin Juergen Hoeller wrote: >Developers, > >I intend to create a Spring 1.2 maintenance branch now that 1.2.5 has been >released. Not a problem per se, but I'm wondering about the branch name :-) > >We have "release-1-2-5" style as tag names, so what could we use as >maintenance branch name? "maintenance-1-2"? "1-2-maintenance"? Any >suggestions? > >Juergen > > > > >------------------------------------------------------- >SF.Net email is sponsored by: >Tame your development challenges with Apache's Geronimo App Server. Download >it for free - -and be entered to win a 42" plasma tv or your very own >Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Juergen H. <ju...@in...> - 2005-09-23 00:28:43
|
Developers, I intend to create a Spring 1.2 maintenance branch now that 1.2.5 has been released. Not a problem per se, but I'm wondering about the branch name :-) We have "release-1-2-5" style as tag names, so what could we use as maintenance branch name? "maintenance-1-2"? "1-2-maintenance"? Any suggestions? Juergen |
|
From: Juergen H. <ju...@in...> - 2005-09-23 00:23:18
|
Dear Spring community, I'm pleased to announce that Spring 1.2.5 has just been released. This is a bugfix and minor enhancement release, fixing a number of issues found in previous 1.2.x releases and introducing various minor new features. See the changelog for details. Cheers, Juergen ----- Juergen Hoeller Interface21 - Spring Services from the Source http://www.springframework.com |
|
From: Juergen H. <ju...@in...> - 2005-09-22 22:22:20
|
In general, I would recommend to not proxy such beans with CGLIB in the first place, but rather use JDK proxies instead - clarifying the actually proxied methods through defining an appropriate service interface, hiding the configuration methods from callers... Nevertheless, I've downgraded that log level from warn to info. I guess it's often non-critical methods that are affected, so a flood of warnings is undesirable. There should nevertheless be a clear indication, which info level should be fine for. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of John Lewis Sent: Thursday, September 22, 2005 10:00 PM To: spr...@li... Subject: [Springframework-developer] Cglib2AopProxy warnings from ApplicationObjectSupport Is it necessary for the getApplicationContext and setApplicationContext methods in org.springframework.context.support.ApplicationObjectSupport to be declared as final? As of 1.2.4, we have a number of beans where org.springframework.aop.framework.Cglib2AopProxy complains about not being able to properly proxy these methods. It's not really a problem since these don't need to have transaction management or security applied to them, but it sure is noisy in the log... 2005-09-22 11:11:03,233 WARN [org.springframework.aop.framework.Cglib2AopProxy] - <Unable to proxy method [public final org.springframework.context.ApplicationContext org.springframework.context.support.ApplicationObjectSupport.getApplicationC ontext() throws java.lang.IllegalStateException] because it is final. All calls to this method via a proxy will be routed directly to the proxy.> 2005-09-22 11:11:03,243 WARN [org.springframework.aop.framework.Cglib2AopProxy] - <Unable to proxy method [public final void org.springframework.context.support.ApplicationObjectSupport.setApplicationC ontext(org.springframework.context.ApplicationContext) throws org.springframework.beans.BeansException] because it is final. All calls to this method via a proxy will be routed directly to the proxy.> John Lewis ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <al...@in...> - 2005-09-22 22:21:09
|
View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050923001626 |
|
From: John L. <jl...@ar...> - 2005-09-22 20:06:08
|
Is it necessary for the getApplicationContext and setApplicationContext methods in org.springframework.context.support.ApplicationObjectSupport to be declared as final? As of 1.2.4, we have a number of beans where org.springframework.aop.framework.Cglib2AopProxy complains about not being able to properly proxy these methods. It's not really a problem since these don't need to have transaction management or security applied to them, but it sure is noisy in the log... 2005-09-22 11:11:03,233 WARN [org.springframework.aop.framework.Cglib2AopProxy] - <Unable to proxy method [public final org.springframework.context.ApplicationContext org.springframework.context.support.ApplicationObjectSupport.getApplicationContext() throws java.lang.IllegalStateException] because it is final. All calls to this method via a proxy will be routed directly to the proxy.> 2005-09-22 11:11:03,243 WARN [org.springframework.aop.framework.Cglib2AopProxy] - <Unable to proxy method [public final void org.springframework.context.support.ApplicationObjectSupport.setApplicationContext(org.springframework.context.ApplicationContext) throws org.springframework.beans.BeansException] because it is final. All calls to this method via a proxy will be routed directly to the proxy.> John Lewis |
|
From: Andy D. <an...@ma...> - 2005-09-22 17:02:49
|
Just saw this announcement over at TSS: http://www.theserverside.com/news/thread.tss?thread_id=36704 The actual site is: http://javaforge.com/ Basically a sourceforge type site for Java projects using Subversion instead of CVS. It's being provided by Javalobby and is still in beta, but something to keep one's eye on. It may be a tempting alternative to sourceforge if it proves to be better managed? - Andy |
|
From: Darren D. <da...@da...> - 2005-09-21 18:43:11
|
On Wed, 2005-09-21 at 11:35 -0400, Colin Sampaleanu wrote: > That was the main reason. Most people don't want to bother (or often=20 > even know about) chaining view resolvers. So since they couldn't rely on=20 > the [Xml|ResourceBundle]ViewResolver being in use and taking care of=20 > this, there was a decent amount of controller code out there that just=20 > did manual instantionations of RedirectView. I always found that pretty=20 > nasty and unclean. A controller just shouldn't know about that kind of=20 > thing. Thanks Colin. Agreed, instantiating a RedirectView in the controller is somewhat less desirable. I just wanted to check that I wasn't missing some other reason (esp. since the info is going into a book). Cheers, --=20 Darren Davison Public Key: 0xDD356B0D |
|
From: Michael E. M. <mm...@re...> - 2005-09-21 16:24:58
|
In AbstractDependencyInjectionSpringContextTests.setUp(),
I can't make the bean get wired by Spring just like any other Spring bean.
The problem occurs when I mess with setPopulateProtectedVariables(true).
I end up with only one of my three dependencies being populated..
protected final void setUp() throws Exception {
this.applicationContext = getContext(contextKey());
if (isPopulateProtectedVariables()) {
if (this.managedVariableNames == null) {
initManagedVariableNames();
}
populateProtectedVariables();
}
else {
this.applicationContext.getBeanFactory().autowireBeanProperties(
this, AutowireCapableBeanFactory.AUTOWIRE_BY_TYPE,
isDependencyCheck());
}
try {
onSetUp();
}
catch (Exception ex) {
logger.error("Setup error", ex);
throw ex;
}
}
Thomas R. Corbin wrote:
>On Tuesday, 20 September 2005 10:00 pm, Michael E. Moores wrote:
>
>
>>ok i tried setting the "mpChargeTest" bean autowire property to values
>>"no" and "byName"
>>and it still gets confused by the testDaoX bean- the one that is proxied.
>>
>>
>
> Try calling this in your constructor:
>
> setPopulateProtectedVariables( true );
>
> Then any protected member data that matches the name of a bean will be filled
>in.
>
> protected Whatever mpChargeTest;
>
>
>
>>Michael E. Moores wrote:
>>
>>
>>>I just swapped in AbstractDependencyInjectionSpringContextTests,
>>>and I end up with an error message That I don't understand at all.
>>>Why would spring complain about autowire problems when I'm not using
>>>autowire???
>>>"There are 2 beans of type [interface com.real.test.mpm.dao.ITestDao]
>>>for autowire by type. There should have been 1 to be able to autowi
>>>re property 'testDao' of bean 'com.real.test.mpm.jaxrpc.TestMpCharge2'."
>>>
>>>
>>><bean id="testDaoTarget" class="com.real.test.mpm.dao.TestDao">
>>> <property name="sessionFactory" ref="testSessionFactory"/>
>>> </bean>
>>><bean id="testDaoX"
>>>class="org.springframework.transaction.interceptor.TransactionProxyFactor
>>>yBean">
>>>
>>> <property name="transactionManager"><ref
>>>bean="testTransactionManager"/></property>
>>> <property name="target"><ref local="testDaoTarget"/></property>
>>> <property name="transactionAttributes">
>>> <props>
>>> <prop key="*">PROPAGATION_REQUIRED</prop>
>>> </props>
>>> </property>
>>></bean>
>>><bean name="mpChargeTest" class="com.real.test.mpm.jaxrpc.TestMpCharge2">
>>> <property name="testDao"><ref local="testDaoX"/></property>
>>> <property name="service" ref="micropaymentService"/>
>>> <property name="musicStoreService" ref="testMusicStoreService"/>
>>></bean>
>>>
>>>
>>>Testcase: testMpCharge took 4.631 sec
>>> Caused an ERROR
>>>Error creating bean with name 'com.real.test.mpm.jaxrpc.TestMpCharge2'
>>>defined in null: Unsatisfied dependency expressed through bean
>>>property 't
>>>estDao': There are 2 beans of type [interface
>>>com.real.test.mpm.dao.ITestDao] for autowire by type. There should
>>>have been 1 to be able to autowi
>>>re property 'testDao' of bean 'com.real.test.mpm.jaxrpc.TestMpCharge2'.
>>>org.springframework.beans.factory.UnsatisfiedDependencyException:
>>>Error creating bean with name 'com.real.test.mpm.jaxrpc.TestMpCharge2'
>>>defined
>>>in null: Unsatisfied dependency expressed through bean property
>>>'testDao': There are 2 beans of type [interface
>>>com.real.test.mpm.dao.ITestDao] f
>>>or autowire by type. There should have been 1 to be able to autowire
>>>property 'testDao' of bean 'com.real.test.mpm.jaxrpc.TestMpCharge2'.
>>> at
>>>org.springframework.beans.factory.support.AbstractAutowireCapableBeanFact
>>>ory.autowireByType(AbstractAutowireCapableBeanFactory.java:89
>>>
>>>6)
>>> at
>>>org.springframework.beans.factory.support.AbstractAutowireCapableBeanFact
>>>ory.populateBean(AbstractAutowireCapableBeanFactory.java:816)
>>>
>>> at
>>>org.springframework.beans.factory.support.AbstractAutowireCapableBeanFact
>>>ory.autowireBeanProperties(AbstractAutowireCapableBeanFactory
>>>
>>>.java:200)
>>> at
>>>org.springframework.test.AbstractDependencyInjectionSpringContextTests.se
>>>tUp(AbstractDependencyInjectionSpringContextTests.java:138)
>>>
>>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by:
>>Tame your development challenges with Apache's Geronimo App Server.
>>Download it for free - -and be entered to win a 42" plasma tv or your very
>>own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
>>_______________________________________________
>>Springframework-user mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-user
>>
>>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by:
>Tame your development challenges with Apache's Geronimo App Server. Download
>it for free - -and be entered to win a 42" plasma tv or your very own
>Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
>_______________________________________________
>Springframework-user mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-user
>
>
>
>
|
|
From: Bing R. <br...@cc...> - 2005-09-21 16:22:45
|
Hi Dave,=20 Working at the getBean() (I assume you meant this method) level is too = high that I cannot control the creation of dependent objects. For instance, = if bean a depends on bean b, which is actually a web session-scoped bean, overriding getBean() for "a" does not allow me easily set b on a. By the time a is created, a new instance of b is already injected into a. I = then need to introspect a to find out b and replace it. Not quite efficient = and easy.=20 It might work, but I'd like to find out a cleaner solution.=20 Thanks. Bing =B7=A2=BC=FE=C8=CB: = spr...@li... [mailto:spr...@li...] = =B4=FA=B1=ED David Hewitt =B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA9=D4=C221=C8=D5 23:04 =CA=D5=BC=FE=C8=CB: spr...@li... =D6=F7=CC=E2: RE: [Springframework-developer] customized BeanFactory Bing, What's wrong with using a standard FactoryBean to do this? Your (non-singleton) FactoryBean could take the value-binding expression parameter, evaluate it when getObject() is called and the result would = then be injected into your property as normal. Its less terse, but is there any reason why this wouldn't work? Dave Hewitt > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On = Behalf > Of Bing Ran > Sent: 21 September 2005 13:08 > To: spr...@li... > Subject: Re: [Springframework-developer] customized BeanFactory >=20 > Thanks Steve. Unfortunately the way that the > PropertyPlaceHolderBeanfactory > Works does not meet my need. What I'd like to have is a repeatable > interpretation of an injected value each time the bean (a prototype) = is > created, rather than the one-time post-processing. What I'm doing is > actually part of my effort to replace the bean management facility of = JSF > with what I'm doing on top of Spring (see http://jacn.sf.net). I need = the > ability to re-evaluate a JSF value-binding expression such as > #{param.user_name}, which binds to a parameter in the http request, = which > of > course is different every time a new request comes in. >=20 > Any insight into this? >=20 > Bing >=20 >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: = spr...@li... > [mailto:spr...@li...] = =B4=FA=B1=ED Steven > Devijver > =B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA9=D4=C221=C8=D5 17:47 > =CA=D5=BC=FE=C8=CB: spr...@li... > =D6=F7=CC=E2: Re: [Springframework-developer] customized BeanFactory >=20 > Bing, >=20 > You can implement a BeanFactoryPostProcessor to do that. Have a look > at the code of PropertyPlaceholderConfigurer. This class inspects > bean definitions and replaces ${key} with property values loaded from > property files. BeanFactoryPostProcessors are recognized by the bean > factory and applied automatically. >=20 > Steven Devijver > Senior consultant > @ Interface21 > ste...@in... >=20 >=20 >=20 > On 21 Sep 2005, at 04:20, Bing Ran wrote: >=20 >=20 > > I'm implementing my own BeanFactory as a subclass of > > DefaultListableBeanFactory. What I want to do is to reinterpret > > injected > > values on a bean, such as the <value>#{param.userName}</value> part > > in the > > bean definition: > > > > <bean ...> > > <property name=3D"a"> <value>#{param.userName}</value></property> > > </bean> > > > > I'd like to set the value from another source (such as in JSF > > context) at > > the time the bean is instantiated. Any tips how my code can get a > > chance to > > re-interpret the dependency? > > > > Thanks! > > > > Bing Ran > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: > > Tame your development challenges with Apache's Geronimo App Server. > > Download > > it for free - -and be entered to win a 42" plasma tv or your very = own > > Sony(tm)PSP. Click here to play: = http://sourceforge.net/geronimo.php > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > = https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > > >=20 >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 > = ________________________________________________________________________ > This e-mail has been scanned for all viruses by Star. The > service is powered by MessageLabs. For more information on a proactive > anti-virus service working around the clock, around the globe, visit: > http://www.star.net.uk > = ________________________________________________________________________ ________________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. = Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2005-09-21 15:35:51
|
That was the main reason. Most people don't want to bother (or often even know about) chaining view resolvers. So since they couldn't rely on the [Xml|ResourceBundle]ViewResolver being in use and taking care of this, there was a decent amount of controller code out there that just did manual instantionations of RedirectView. I always found that pretty nasty and unclean. A controller just shouldn't know about that kind of thing. Colin Darren Davison wrote: >Hi all, > >The "redirect:" prefix that was added as a feature last year enables >controllers to remain ignorant of the redirect since the String value >containing the prefix can be injected into the controller bean. That much I >understand. > >What I'm wondering is whether there was another benefit, or problem solved, by >taking this route? It seems to be a natural limitation of the choice of >ViewResolver that the problem actually solves.. if the app is using a >UrlBasedViewResolver or subclass, the redirect: prefix is needed. > >However, if the app defined an [Xml|ResourceBundle]ViewResolver and ordered it >first, then that could be used to resolve redirect views, falling back to the >UrlBasedViewResolver for everything else. It looks like this would mitigate >the need for the special handling of view name prefixes. > >I can't see anything in the discussions or JIRA issues from around the time >this feature was added eluding to this other than a comment I made myself [1], >so am I missing something here? > >[1] http://opensource2.atlassian.com/projects/spring/browse/SPR-387 > >Regards, > > |
|
From: David H. <dh...@ob...> - 2005-09-21 15:07:15
|
Bing, What's=20wrong=20with=20using=20a=20standard=20FactoryBean=20to=20do=20thi= s?=20Your=20(non-singleton)=20FactoryBean=20could=20take=20the=20value-bin= ding=20expression=20parameter,=20evaluate=20it=20when=20getObject()=20is=20= called=20and=20the=20result=20would=20then=20be=20injected=20into=20your=20= property=20as=20normal. Its=20less=20terse,=20but=20is=20there=20any=20reason=20why=20this=20would= n't=20work? Dave=20Hewitt >=20-----Original=20Message----- >=20From:=20s...@li... >=20[mailto:spr...@li...]=20On=20= Behalf >=20Of=20Bing=20Ran >=20Sent:=2021=20September=202005=2013:08 >=20To:=20s...@li... >=20Subject:=20Re:=20[Springframework-developer]=20customized=20BeanFactor= y >=20 >=20Thanks=20Steve.=20Unfortunately=20the=20way=20that=20the >=20PropertyPlaceHolderBeanfactory >=20Works=20does=20not=20meet=20my=20need.=20What=20I'd=20like=20to=20have= =20is=20a=20repeatable >=20interpretation=20of=20an=20injected=20value=20each=20time=20the=20bean= =20(a=20prototype)=20is >=20created,=20rather=20than=20the=20one-time=20post-processing.=20What=20= I'm=20doing=20is >=20actually=20part=20of=20my=20effort=20to=20replace=20the=20bean=20manag= ement=20facility=20of=20JSF >=20with=20what=20I'm=20doing=20on=20top=20of=20Spring=20(see=20http://jac= n.sf.net).=20I=20need=20the >=20ability=20to=20re-evaluate=20a=20JSF=20value-binding=20expression=20su= ch=20as >=20#{param.user_name},=20which=20binds=20to=20a=20parameter=20in=20the=20= http=20request,=20which >=20of >=20course=20is=20different=20every=20time=20a=20new=20request=20comes=20i= n. >=20 >=20Any=20insight=20into=20this? >=20 >=20Bing >=20 >=20 >=20-----=D3=CA=BC=FE=D4=AD=BC=FE----- >=20=B7=A2=BC=FE=C8=CB:=20s...@li...= e.net >=20[mailto:spr...@li...]=20=B4=FA= =B1=ED=20Steven >=20Devijver >=20=B7=A2=CB=CD=CA=B1=BC=E4:=202005=C4=EA9=D4=C221=C8=D5=2017:47 >=20=CA=D5=BC=FE=C8=CB:=20s...@li... >=20=D6=F7=CC=E2:=20Re:=20[Springframework-developer]=20customized=20BeanF= actory >=20 >=20Bing, >=20 >=20You=20can=20implement=20a=20BeanFactoryPostProcessor=20to=20do=20that.= =20Have=20a=20look >=20at=20the=20code=20of=20PropertyPlaceholderConfigurer.=20This=20class=20= inspects >=20bean=20definitions=20and=20replaces=20${key}=20with=20property=20value= s=20loaded=20from >=20property=20files.=20BeanFactoryPostProcessors=20are=20recognized=20by=20= the=20bean >=20factory=20and=20applied=20automatically. >=20 >=20Steven=20Devijver >=20Senior=20consultant >=20@=20Interface21 >=20s...@in... >=20 >=20 >=20 >=20On=2021=20Sep=202005,=20at=2004:20,=20Bing=20Ran=20wrote: >=20 >=20 >=20>=20I'm=20implementing=20my=20own=20BeanFactory=20as=20a=20subclass=20= of >=20>=20DefaultListableBeanFactory.=20What=20I=20want=20to=20do=20is=20to=20= reinterpret >=20>=20injected >=20>=20values=20on=20a=20bean,=20such=20as=20the=20<value>#{param.userNam= e}</value>=20part >=20>=20in=20the >=20>=20bean=20definition: >=20> >=20>=20<bean=20...> >=20>=20=20=20<property=20name=3D"a">=20<value>#{param.userName}</value></= property> >=20>=20</bean> >=20> >=20>=20I'd=20like=20to=20set=20the=20value=20from=20another=20source=20(s= uch=20as=20in=20JSF >=20>=20context)=20at >=20>=20the=20time=20the=20bean=20is=20instantiated.=20Any=20tips=20how=20= my=20code=20can=20get=20a >=20>=20chance=20to >=20>=20re-interpret=20the=20dependency? >=20> >=20>=20Thanks! >=20> >=20>=20Bing=20Ran >=20> >=20> >=20> >=20> >=20>=20------------------------------------------------------- >=20>=20SF.Net=20email=20is=20sponsored=20by: >=20>=20Tame=20your=20development=20challenges=20with=20Apache's=20Geronim= o=20App=20Server. >=20>=20Download >=20>=20it=20for=20free=20-=20-and=20be=20entered=20to=20win=20a=2042"=20p= lasma=20tv=20or=20your=20very=20own >=20>=20Sony(tm)PSP.=20=20Click=20here=20to=20play:=20http://sourceforge.n= et/geronimo.php >=20>=20_______________________________________________ >=20>=20Springframework-developer=20mailing=20list >=20>=20S...@li... >=20>=20https://lists.sourceforge.net/lists/listinfo/springframework-devel= oper >=20> >=20> >=20> >=20 >=20 >=20 >=20 >=20------------------------------------------------------- >=20SF.Net=20email=20is=20sponsored=20by: >=20Tame=20your=20development=20challenges=20with=20Apache's=20Geronimo=20= App=20Server. >=20Download >=20it=20for=20free=20-=20-and=20be=20entered=20to=20win=20a=2042"=20plasm= a=20tv=20or=20your=20very=20own >=20Sony(tm)PSP.=20=20Click=20here=20to=20play:=20http://sourceforge.net/g= eronimo.php >=20_______________________________________________ >=20Springframework-developer=20mailing=20list >=20S...@li... >=20https://lists.sourceforge.net/lists/listinfo/springframework-developer= >=20 >=20 >=20 >=20------------------------------------------------------- >=20SF.Net=20email=20is=20sponsored=20by: >=20Tame=20your=20development=20challenges=20with=20Apache's=20Geronimo=20= App=20Server. >=20Download >=20it=20for=20free=20-=20-and=20be=20entered=20to=20win=20a=2042"=20plasm= a=20tv=20or=20your=20very=20own >=20Sony(tm)PSP.=20=20Click=20here=20to=20play:=20http://sourceforge.net/g= eronimo.php >=20_______________________________________________ >=20Springframework-developer=20mailing=20list >=20S...@li... >=20https://lists.sourceforge.net/lists/listinfo/springframework-developer= >=20 >=20______________________________________________________________________= __ >=20This=20e-mail=20has=20been=20scanned=20for=20all=20viruses=20by=20Star= .=20The >=20service=20is=20powered=20by=20MessageLabs.=20For=20more=20information=20= on=20a=20proactive >=20anti-virus=20service=20working=20around=20the=20clock,=20around=20the=20= globe,=20visit: >=20http://www.star.net.uk >=20______________________________________________________________________= __ ________________________________________________________________________ This=20e-mail=20has=20been=20scanned=20for=20all=20viruses=20by=20Star.=20= The service=20is=20powered=20by=20MessageLabs.=20For=20more=20information=20on= =20a=20proactive anti-virus=20service=20working=20around=20the=20clock,=20around=20the=20gl= obe,=20visit: http://www.star.net.uk ________________________________________________________________________ |
|
From: Steven D. <ste...@in...> - 2005-09-21 13:38:31
|
Erwin,
The AJAX component I'm talking about makes a request to the SWF
controller with _flowExecutionId and _eventId parameters and replaces
the inner HTML of a div tag with the HTML returned by SWF. From the
SWF perspective not much changes.
<div id="miniWizard">
<form>
<label>Departure city</label><input type="text"
name="departure"><br>
<label>Destination city</label><input type="text"
name="destination"><br>
<input type="hidden" name="_eventId" value="myAjaxEvent">
<input type="hidden" name="_flowExecutionId" value="$
{flowExecutionId}">
<input type="button" value="Submit" id="submitButton">
<ajax:sendRequest elementId="miniWizard"
buttonId="submitButton" url="..."/>
</form>
</div>
SWF could start asynchronous flow executions from the scope of an
existing flow execution to make AJAX integration more powerful.
Steven
On 21 Sep 2005, at 14:45, Erwin Vervaet wrote:
> Steven,
>
> I must admit I've never used AJAX stuff in the real world, so I
> might just be missing something, but could you try to explain why
> SWF is so usefull for AJAX based 'mini wizards'?
>
> Naively I would say that SWF and AJAX are pretty orthogonal: SWF
> managing the high-level flow of a wizard for instance, AJAX being
> used to pull in dynamic data at particular pages in the wizard. So
> it seems that at the server side, the flow and the AJAX controllers
> are pretty much independent. I can imagine some AJAX controller
> pulling dynamic data from some data source and returning it as XML
> is used both in a SWF managed wizard and from another stand-alone
> page, possibly a simple HTML page.
>
> Erwin Vervaet
> erw...@er...
> ----- Original Message ----- From: "Steven Devijver"
> <ste...@in...>
> To: <spr...@li...>
> Sent: Wednesday, September 21, 2005 12:16 PM
> Subject: Re: [Springframework-developer] new feature proposal for
> SWF: asynchronous flows
>
>
>
>> Erwin,
>>
>> On 21 Sep 2005, at 10:58, Erwin Vervaet wrote:
>>
>>
>>> We already have asynchronous flows: you can start any number of
>>> top- level flow executions concurrently.
>>>
>>> So what exactly is the benefit of the additional support you
>>> describe? Why can't you just use a subflow or a second
>>> independent top-level flow for those 'mini wizards' you
>>> describe? I'm not sure all the added complexity really pays off...
>>>
>>>
>> Subflows are not the same thing since they require a transition
>> of the parent flow execution. Either each step in a mini-wizard
>> would then require a separate view template for the entire page,
>> not just the section. Or javascript code makes the call and
>> triggers the transition of the parent flow execution. This would
>> mean all other possible transitions in other sections of the page
>> become unavailable.
>>
>> Top-level flows that are executed via javascript solve this
>> problem since the parent or original flow execution is not
>> transitioned. However, no scope data can be copied between the
>> original flow and request scope and the new flow scope. Making
>> the transition on the parent could be achieved through javascript
>> but that's leaves the developer with boilerplate javascript code.
>>
>>
>>> Stuff like "When the view state of the parent transitions the
>>> flow executions of the asynchronous flows are terminated. The
>>> FlowAttributeMapper can be used in the same way as with sub
>>> states to map scope attributes between a parent flow and
>>> asynchronous flows." and "In this scenario it may be desirable
>>> to allow an end state of an asynchronous flow to trigger the
>>> transition of the view state of the parent" is a bit strange
>>> IMHO: if you want that kind of stuff, just use subflows and a
>>> flow execution listener.
>>>
>>>
>> Again, I don't agree. To me these semantics make sense from an
>> AJAX perspective. Subflows are great to synchronously execute page
>> flows. AJAX however is about asynchronous execution.
>>
>>
>>> Also, it seems that terminating all started asynchronous flows
>>> when the 'parent' transitions could lead to a number of issues.
>>> What if a client spawned multiple ansynchronous flows and one
>>> triggers a transition in the parent. As a result all those 'mini
>>> wizards' would become unusable...
>>>
>>
>> On the other hand, if you call top-level flows asynchronously
>> thru AJAX they become stale once the original flow execution
>> transitions. About the issues that could arise by terminating
>> asynchronous flows: they are real and in my opinion unavoidable
>> but should be dealt with by the developer. Once you start using
>> AJAX on your website thru the functionality I propose you may
>> want to use it in multiple levels meaning other asynchronous flow
>> executions will not be terminated just like that. It's a design
>> choice and AJAX is a very popular one. I think it's up to the
>> developers to decide how they want to use SWF.
>>
>>
>>>
>>> Erwin
>>>
>>
>> Steven
>>
>>
>>>
>>>
>>>
>>>> I've skyped with Keith today about a new feature I would like
>>>> to see added to SWF: asynchronous flows (useful with AJAX
>>>> technology).
>>>>
>>>> Asynchronous flows are normal SWF flows that are launched
>>>> asynchronously from a view state, typically thru AJAX calls,
>>>> separate browser windows or frames.
>>>>
>>>> An asynchronous flow is thus a flow definition that is started
>>>> through an event id that's defined in a view state:
>>>>
>>>> <view-state id="myViewState" view="myView">
>>>> <transition on="submit" to="myActionState"/>
>>>> <async-flow on="myAsyncEvent" flow="myAsyncFlow"/>
>>>> </view-state>
>>>>
>>>> When an asynchronous flow is launched the parent flow execution
>>>> is not transitioned. Asynchronous events are accessible
>>>> through the flow execution id of the parent. When an
>>>> asynchronous flow has been started a new flow execution is
>>>> created and that flow execution is referenced to by a new flow
>>>> execution id. This allows for multiple invocations of the same
>>>> asynchronous flow by the same client. When an asynchronous
>>>> flow execution ends it can trigger the transition of the
>>>> parent view state (more on that later).
>>>>
>>>> Otherwise asynchronous flows have the exact same behavior of
>>>> normal SWF flows. They can have action states, view states,
>>>> subflow states and decision states. When the view state of the
>>>> parent transitions the flow executions of the asynchronous
>>>> flows are terminated. The FlowAttributeMapper can be used in
>>>> the same way as with sub states to map scope attributes between
>>>> a parent flow and asynchronous flows.
>>>>
>>>> A typical use case for an asynchronous flow is a mini-wizard
>>>> contained as a widget in a view. The asynchronous flow is
>>>> launched by an AJAX client-side HTTP component that replaces
>>>> the inner html of a div tag with the html send back by the
>>>> view states of the asynchronous flow (a normal JSP views for
>>>> example). We probably need a JSP tag that renders the client-
>>>> side JavaScript:
>>>>
>>>> <ajax:sendRequest eventId="myMiniEvent" flowExecutionId="$
>>>> {flowExecutionId}"/>
>>>>
>>>> This JSP tag can than be used in the views of asynchronous
>>>> flows to mimic browser behaviour. This feature could make
>>>> creating mini- wizards child's play. It should be noted that
>>>> when the view is shown by the browser and the JavaScript code
>>>> of the JSP tag kicks it will immediately launch a call to the
>>>> asynchronous event. A optimization could be to let this JSP tag
>>>> execute the call to asynchronous flow on the server if that's
>>>> feasible.
>>>>
>>>> An example of a AJAX mini-wizard is a section on the site of a
>>>> travel booking agent where:
>>>>
>>>> - your can enter a departure and destination city on the first
>>>> page
>>>> - next a page to confirm the names of the cities
>>>> - then a page to select the dates of departure and return and
>>>> - then a page with a list of available flights
>>>>
>>>> In this scenario it may be desirable to allow an end state of an
>>>> asynchronous flow to trigger the transition of the view state
>>>> of the parent, for example when a flight in the mini-wizard is
>>>> clicked on. Since the flow execution of the mini-flow only
>>>> knows its own flow execution id the id of the parent cannot be
>>>> used. For this scenario we could use the name of the
>>>> asynchronous flow + the name of the end state as the event name
>>>> of a transition on the parent view state:
>>>>
>>>> <view state ...>
>>>> <async-flow on="myAsyncEvent" flow="myAsyncFlow"/>
>>>> <transition on="myAsyncFlow.myEndState" to="myNextState"/>
>>>> </view-state>
>>>>
>>>> Mini-wizards can also be displayed in a pop up browser window
>>>> when selecting items to complete a form, for example to select
>>>> products in an order form. These mini-wizards obviously also
>>>> can be implemented as AJAX mini-wizards.
>>>>
>>>> Any thoughts?
>>>>
>>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF.Net email is sponsored by:
>>> Tame your development challenges with Apache's Geronimo App
>>> Server. Download
>>> it for free - -and be entered to win a 42" plasma tv or your very
>>> own
>>> Sony(tm)PSP. Click here to play: http://sourceforge.net/
>>> geronimo.php
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-
>>> developer
>>>
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by:
>> Tame your development challenges with Apache's Geronimo App
>> Server. Download
>> it for free - -and be entered to win a 42" plasma tv or your very own
>> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-
>> developer
>>
>>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
|
|
From: Erwin V. <erw...@er...> - 2005-09-21 12:41:05
|
Steven,
I must admit I've never used AJAX stuff in the real world, so I might just
be missing something, but could you try to explain why SWF is so usefull for
AJAX based 'mini wizards'?
Naively I would say that SWF and AJAX are pretty orthogonal: SWF managing
the high-level flow of a wizard for instance, AJAX being used to pull in
dynamic data at particular pages in the wizard. So it seems that at the
server side, the flow and the AJAX controllers are pretty much independent.
I can imagine some AJAX controller pulling dynamic data from some data
source and returning it as XML is used both in a SWF managed wizard and from
another stand-alone page, possibly a simple HTML page.
Erwin Vervaet
erw...@er...
----- Original Message -----
From: "Steven Devijver" <ste...@in...>
To: <spr...@li...>
Sent: Wednesday, September 21, 2005 12:16 PM
Subject: Re: [Springframework-developer] new feature proposal for SWF:
asynchronous flows
> Erwin,
>
> On 21 Sep 2005, at 10:58, Erwin Vervaet wrote:
>
>> We already have asynchronous flows: you can start any number of top-
>> level flow executions concurrently.
>>
>> So what exactly is the benefit of the additional support you describe?
>> Why can't you just use a subflow or a second independent top-level flow
>> for those 'mini wizards' you describe? I'm not sure all the added
>> complexity really pays off...
>>
> Subflows are not the same thing since they require a transition of the
> parent flow execution. Either each step in a mini-wizard would then
> require a separate view template for the entire page, not just the
> section. Or javascript code makes the call and triggers the transition of
> the parent flow execution. This would mean all other possible transitions
> in other sections of the page become unavailable.
>
> Top-level flows that are executed via javascript solve this problem since
> the parent or original flow execution is not transitioned. However, no
> scope data can be copied between the original flow and request scope and
> the new flow scope. Making the transition on the parent could be achieved
> through javascript but that's leaves the developer with boilerplate
> javascript code.
>
>> Stuff like "When the view state of the parent transitions the flow
>> executions of the asynchronous flows are terminated. The
>> FlowAttributeMapper can be used in the same way as with sub states to
>> map scope attributes between a parent flow and asynchronous flows." and
>> "In this scenario it may be desirable to allow an end state of an
>> asynchronous flow to trigger the transition of the view state of the
>> parent" is a bit strange IMHO: if you want that kind of stuff, just use
>> subflows and a flow execution listener.
>>
> Again, I don't agree. To me these semantics make sense from an AJAX
> perspective. Subflows are great to synchronously execute page flows. AJAX
> however is about asynchronous execution.
>
>> Also, it seems that terminating all started asynchronous flows when the
>> 'parent' transitions could lead to a number of issues. What if a client
>> spawned multiple ansynchronous flows and one triggers a transition in
>> the parent. As a result all those 'mini wizards' would become
>> unusable...
>
> On the other hand, if you call top-level flows asynchronously thru AJAX
> they become stale once the original flow execution transitions. About the
> issues that could arise by terminating asynchronous flows: they are real
> and in my opinion unavoidable but should be dealt with by the developer.
> Once you start using AJAX on your website thru the functionality I
> propose you may want to use it in multiple levels meaning other
> asynchronous flow executions will not be terminated just like that. It's
> a design choice and AJAX is a very popular one. I think it's up to the
> developers to decide how they want to use SWF.
>
>>
>> Erwin
>
> Steven
>
>>
>>
>>> I've skyped with Keith today about a new feature I would like to see
>>> added to SWF: asynchronous flows (useful with AJAX technology).
>>>
>>> Asynchronous flows are normal SWF flows that are launched
>>> asynchronously from a view state, typically thru AJAX calls, separate
>>> browser windows or frames.
>>>
>>> An asynchronous flow is thus a flow definition that is started through
>>> an event id that's defined in a view state:
>>>
>>> <view-state id="myViewState" view="myView">
>>> <transition on="submit" to="myActionState"/>
>>> <async-flow on="myAsyncEvent" flow="myAsyncFlow"/>
>>> </view-state>
>>>
>>> When an asynchronous flow is launched the parent flow execution is not
>>> transitioned. Asynchronous events are accessible through the flow
>>> execution id of the parent. When an asynchronous flow has been started
>>> a new flow execution is created and that flow execution is referenced
>>> to by a new flow execution id. This allows for multiple invocations of
>>> the same asynchronous flow by the same client. When an asynchronous
>>> flow execution ends it can trigger the transition of the parent view
>>> state (more on that later).
>>>
>>> Otherwise asynchronous flows have the exact same behavior of normal
>>> SWF flows. They can have action states, view states, subflow states
>>> and decision states. When the view state of the parent transitions the
>>> flow executions of the asynchronous flows are terminated. The
>>> FlowAttributeMapper can be used in the same way as with sub states to
>>> map scope attributes between a parent flow and asynchronous flows.
>>>
>>> A typical use case for an asynchronous flow is a mini-wizard contained
>>> as a widget in a view. The asynchronous flow is launched by an AJAX
>>> client-side HTTP component that replaces the inner html of a div tag
>>> with the html send back by the view states of the asynchronous flow (a
>>> normal JSP views for example). We probably need a JSP tag that renders
>>> the client-side JavaScript:
>>>
>>> <ajax:sendRequest eventId="myMiniEvent" flowExecutionId="$
>>> {flowExecutionId}"/>
>>>
>>> This JSP tag can than be used in the views of asynchronous flows to
>>> mimic browser behaviour. This feature could make creating mini- wizards
>>> child's play. It should be noted that when the view is shown by the
>>> browser and the JavaScript code of the JSP tag kicks it will
>>> immediately launch a call to the asynchronous event. A optimization
>>> could be to let this JSP tag execute the call to asynchronous flow on
>>> the server if that's feasible.
>>>
>>> An example of a AJAX mini-wizard is a section on the site of a travel
>>> booking agent where:
>>>
>>> - your can enter a departure and destination city on the first page
>>> - next a page to confirm the names of the cities
>>> - then a page to select the dates of departure and return and
>>> - then a page with a list of available flights
>>>
>>> In this scenario it may be desirable to allow an end state of an
>>> asynchronous flow to trigger the transition of the view state of the
>>> parent, for example when a flight in the mini-wizard is clicked on.
>>> Since the flow execution of the mini-flow only knows its own flow
>>> execution id the id of the parent cannot be used. For this scenario we
>>> could use the name of the asynchronous flow + the name of the end
>>> state as the event name of a transition on the parent view state:
>>>
>>> <view state ...>
>>> <async-flow on="myAsyncEvent" flow="myAsyncFlow"/>
>>> <transition on="myAsyncFlow.myEndState" to="myNextState"/>
>>> </view-state>
>>>
>>> Mini-wizards can also be displayed in a pop up browser window when
>>> selecting items to complete a form, for example to select products in
>>> an order form. These mini-wizards obviously also can be implemented as
>>> AJAX mini-wizards.
>>>
>>> Any thoughts?
>>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by:
>> Tame your development challenges with Apache's Geronimo App Server.
>> Download
>> it for free - -and be entered to win a 42" plasma tv or your very own
>> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
|
|
From: Bing R. <br...@cc...> - 2005-09-21 12:08:08
|
Thanks Steve. Unfortunately the way that the = PropertyPlaceHolderBeanfactory Works does not meet my need. What I'd like to have is a repeatable interpretation of an injected value each time the bean (a prototype) is created, rather than the one-time post-processing. What I'm doing is actually part of my effort to replace the bean management facility of = JSF with what I'm doing on top of Spring (see http://jacn.sf.net). I need = the ability to re-evaluate a JSF value-binding expression such as #{param.user_name}, which binds to a parameter in the http request, = which of course is different every time a new request comes in.=20 Any insight into this? Bing=20 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: = spr...@li... [mailto:spr...@li...] = =B4=FA=B1=ED Steven Devijver =B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA9=D4=C221=C8=D5 17:47 =CA=D5=BC=FE=C8=CB: spr...@li... =D6=F7=CC=E2: Re: [Springframework-developer] customized BeanFactory Bing, You can implement a BeanFactoryPostProcessor to do that. Have a look =20 at the code of PropertyPlaceholderConfigurer. This class inspects =20 bean definitions and replaces ${key} with property values loaded from =20 property files. BeanFactoryPostProcessors are recognized by the bean =20 factory and applied automatically. Steven Devijver Senior consultant @ Interface21 ste...@in... On 21 Sep 2005, at 04:20, Bing Ran wrote: > I'm implementing my own BeanFactory as a subclass of > DefaultListableBeanFactory. What I want to do is to reinterpret =20 > injected > values on a bean, such as the <value>#{param.userName}</value> part =20 > in the > bean definition: > > <bean ...> > <property name=3D"a"> <value>#{param.userName}</value></property> > </bean> > > I'd like to set the value from another source (such as in JSF =20 > context) at > the time the bean is instantiated. Any tips how my code can get a =20 > chance to > re-interpret the dependency? > > Thanks! > > Bing Ran > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. =20 > Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. = Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Darren D. <da...@da...> - 2005-09-21 10:34:07
|
Hi all, The "redirect:" prefix that was added as a feature last year enables controllers to remain ignorant of the redirect since the String value containing the prefix can be injected into the controller bean. That much I understand. What I'm wondering is whether there was another benefit, or problem solved,= by taking this route? It seems to be a natural limitation of the choice of ViewResolver that the problem actually solves.. if the app is using a UrlBasedViewResolver or subclass, the redirect: prefix is needed. However, if the app defined an [Xml|ResourceBundle]ViewResolver and ordered= it first, then that could be used to resolve redirect views, falling back to t= he UrlBasedViewResolver for everything else. It looks like this would mitigate the need for the special handling of view name prefixes. I can't see anything in the discussions or JIRA issues from around the time this feature was added eluding to this other than a comment I made myself [= 1], so am I missing something here? [1] http://opensource2.atlassian.com/projects/spring/browse/SPR-387 Regards, --=20 Darren Davison Public Key: 0xDD356B0D |
|
From: Steven D. <ste...@in...> - 2005-09-21 10:13:42
|
Erwin,
On 21 Sep 2005, at 10:58, Erwin Vervaet wrote:
> We already have asynchronous flows: you can start any number of top-
> level flow executions concurrently.
>
> So what exactly is the benefit of the additional support you
> describe? Why can't you just use a subflow or a second independent
> top-level flow for those 'mini wizards' you describe? I'm not sure
> all the added complexity really pays off...
>
Subflows are not the same thing since they require a transition of
the parent flow execution. Either each step in a mini-wizard would
then require a separate view template for the entire page, not just
the section. Or javascript code makes the call and triggers the
transition of the parent flow execution. This would mean all other
possible transitions in other sections of the page become unavailable.
Top-level flows that are executed via javascript solve this problem
since the parent or original flow execution is not transitioned.
However, no scope data can be copied between the original flow and
request scope and the new flow scope. Making the transition on the
parent could be achieved through javascript but that's leaves the
developer with boilerplate javascript code.
> Stuff like "When the view state of the parent transitions the flow
> executions of the asynchronous flows are terminated. The
> FlowAttributeMapper can be used in the same way as with sub states
> to map scope attributes between a parent flow and asynchronous
> flows." and "In this scenario it may be desirable to allow an end
> state of an asynchronous flow to trigger the transition of the
> view state of the parent" is a bit strange IMHO: if you want that
> kind of stuff, just use subflows and a flow execution listener.
>
Again, I don't agree. To me these semantics make sense from an AJAX
perspective. Subflows are great to synchronously execute page flows.
AJAX however is about asynchronous execution.
> Also, it seems that terminating all started asynchronous flows when
> the 'parent' transitions could lead to a number of issues. What if
> a client spawned multiple ansynchronous flows and one triggers a
> transition in the parent. As a result all those 'mini wizards'
> would become unusable...
On the other hand, if you call top-level flows asynchronously thru
AJAX they become stale once the original flow execution transitions.
About the issues that could arise by terminating asynchronous flows:
they are real and in my opinion unavoidable but should be dealt with
by the developer. Once you start using AJAX on your website thru the
functionality I propose you may want to use it in multiple levels
meaning other asynchronous flow executions will not be terminated
just like that. It's a design choice and AJAX is a very popular one.
I think it's up to the developers to decide how they want to use SWF.
>
> Erwin
Steven
>
>
>> I've skyped with Keith today about a new feature I would like to
>> see added to SWF: asynchronous flows (useful with AJAX technology).
>>
>> Asynchronous flows are normal SWF flows that are launched
>> asynchronously from a view state, typically thru AJAX calls,
>> separate browser windows or frames.
>>
>> An asynchronous flow is thus a flow definition that is started
>> through an event id that's defined in a view state:
>>
>> <view-state id="myViewState" view="myView">
>> <transition on="submit" to="myActionState"/>
>> <async-flow on="myAsyncEvent" flow="myAsyncFlow"/>
>> </view-state>
>>
>> When an asynchronous flow is launched the parent flow execution
>> is not transitioned. Asynchronous events are accessible through
>> the flow execution id of the parent. When an asynchronous flow has
>> been started a new flow execution is created and that flow
>> execution is referenced to by a new flow execution id. This
>> allows for multiple invocations of the same asynchronous flow by
>> the same client. When an asynchronous flow execution ends it can
>> trigger the transition of the parent view state (more on that
>> later).
>>
>> Otherwise asynchronous flows have the exact same behavior of
>> normal SWF flows. They can have action states, view states,
>> subflow states and decision states. When the view state of the
>> parent transitions the flow executions of the asynchronous flows
>> are terminated. The FlowAttributeMapper can be used in the same
>> way as with sub states to map scope attributes between a parent
>> flow and asynchronous flows.
>>
>> A typical use case for an asynchronous flow is a mini-wizard
>> contained as a widget in a view. The asynchronous flow is launched
>> by an AJAX client-side HTTP component that replaces the inner
>> html of a div tag with the html send back by the view states of
>> the asynchronous flow (a normal JSP views for example). We
>> probably need a JSP tag that renders the client-side JavaScript:
>>
>> <ajax:sendRequest eventId="myMiniEvent" flowExecutionId="$
>> {flowExecutionId}"/>
>>
>> This JSP tag can than be used in the views of asynchronous flows
>> to mimic browser behaviour. This feature could make creating
>> mini- wizards child's play. It should be noted that when the view
>> is shown by the browser and the JavaScript code of the JSP tag
>> kicks it will immediately launch a call to the asynchronous
>> event. A optimization could be to let this JSP tag execute the
>> call to asynchronous flow on the server if that's feasible.
>>
>> An example of a AJAX mini-wizard is a section on the site of a
>> travel booking agent where:
>>
>> - your can enter a departure and destination city on the first page
>> - next a page to confirm the names of the cities
>> - then a page to select the dates of departure and return and
>> - then a page with a list of available flights
>>
>> In this scenario it may be desirable to allow an end state of an
>> asynchronous flow to trigger the transition of the view state of
>> the parent, for example when a flight in the mini-wizard is
>> clicked on. Since the flow execution of the mini-flow only knows
>> its own flow execution id the id of the parent cannot be used.
>> For this scenario we could use the name of the asynchronous flow
>> + the name of the end state as the event name of a transition on
>> the parent view state:
>>
>> <view state ...>
>> <async-flow on="myAsyncEvent" flow="myAsyncFlow"/>
>> <transition on="myAsyncFlow.myEndState" to="myNextState"/>
>> </view-state>
>>
>> Mini-wizards can also be displayed in a pop up browser window when
>> selecting items to complete a form, for example to select products
>> in an order form. These mini-wizards obviously also can be
>> implemented as AJAX mini-wizards.
>>
>> Any thoughts?
>>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
|