springframework-developer — Spring Framework developers list

[Springframework-developer] FAILED BUILD: sparc-solaris1 (last 30 lines included)

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

1121299116
FAILED
    [junit] Testcase: testProxiedUserInterfacesWithMultipleInterfaces took 0.191 sec
    [junit] Testcase: testProxiedUserInterfacesWithNoInterface took 0.059 sec
    [junit] Tests run: 15, Failures: 1, Errors: 0, Time elapsed: 95.636 sec
    [junit] Testsuite: org.springframework.aop.framework.CglibProxyTests
    [junit] Tests run: 15, Failures: 1, Errors: 0, Time elapsed: 95.636 sec
    [junit] ------------- Standard Output ---------------
    [junit] StopWatch '': running time (millis) = 55267
    [junit] [class org.springframework.aop.framework.CglibProxyTests.testManyProxies: create 10000 proxies] took 55267=100%
    [junit] ------------- ---------------- ---------------

    [junit] Testcase: testNullConfig took 1.311 sec
    [junit] Testcase: testNoTarget took 0.4 sec
    [junit] Testcase: testProtectedMethodInvocation took 5.679 sec
    [junit] Testcase: testProxyCanBeClassNotInterface took 2.969 sec
    [junit] Testcase: testCglibProxyingGivesMeaningfulExceptionIfAskedToProxyNonvisibleClass took 0.782 sec
    [junit] Testcase: testMethodInvocationDuringConstructor took 1.341 sec
    [junit] Testcase: testUnadvisedProxyCreationWithCallDuringConstructor took 0.467 sec
    [junit] Testcase: testMultipleProxies took 4.536 sec
    [junit] Testcase: testWithNoArgConstructor took 0.956 sec
    [junit] Testcase: testProxyAProxy took 1.756 sec
    [junit] Testcase: testExceptionHandling took 0.968 sec
    [junit] Testcase: testWithDependencyChecking took 17.218 sec
    [junit] Testcase: testNoInterceptorsAndNoTarget took 0 sec
    [junit] Testcase: testValuesStick took 0.525 sec
    [junit] Testcase: testManyProxies took 55.659 sec
    [junit] 	FAILED
    [junit] Proxy creation was too slow
    [junit] junit.framework.AssertionFailedError: Proxy creation was too slow
    [junit] 	at org.springframework.aop.framework.AbstractAopProxyTests.testManyProxies(AbstractAopProxyTests.java:147)


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.

[Springframework-developer] spring build.305 Build Successful

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

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

Re: [Springframework-developer] Rules code missing?

[Andy D. <an...@ma...>]

On Monday 13 June 2005 04:47 pm, Keith Donald wrote:
> Pardon the work in progress there -- :-)
>
> The Rules code will be moving over to spring modules at java.NET most
> likely.  Can you guys hold without it in CVS for a few days until we get it
> moved over?

Keith,
  I'm wondering if the Rules code has found its new home yet?  I'd like to get 
Spring-rich moved over to Spring 1.2.2, and this is not possible until the 
Rules code (and other related packages) is found.

Thanks,
  Andy

[Springframework-developer] Unable to build sandbox.jar

[Andy D. <an...@ma...>]

I just did a clean CVS checkout of Spring and, after building "alljars", 
attempted to "ant sandbox.jar".  I was greeted with this:

    [javac] Compiling 170 source files to ... spring/target/sandbox/classes
    [javac] ... 
spring/sandbox/src/org/springframework/aop/framework/asm/NonStaticTargetSourceCodeGenerationStrategy.java:153: 
generics are not supported in -source 1.3
    [javac] (try -source 1.5 to enable generics)
    [javac]             Class<?> returnType = method.getReturnType();
    [javac]                      ^
    [javac] 1 error

It seems to me that one should be able to just check out and compile... am I 
mistaken?

  - Andy

Re: [Springframework-developer] Spring 1.2 Support for JDK 1.3

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

I'm a little unclear where that discussion started... Any JDK 1.3
compatibility issues with Spring and/or Acegi?

I can assure you that Spring 1.2.x and also Spring 1.3.x will continue to
support JDK 1.3 as far as possible. In parallel, we do support a number of
JDK 1.4 and 1.5 features where it makes sense, without tying the overall
framework to those versions.

BTW, Spring can currently be built on either JDK 1.5 or 1.4. On 1.4, it will
simply not include the JDK 1.5 support, resulting in slightly smaller jar
files. In any case, almost everything will run on JDK 1.3 as well; Spring is
built with "-target 1.3".

If built on JDK 1.4 ("buildtests"), the test suite can even be run on 1.3
("tests"): all 1.4-dependent tests will simply be excluded then. This is
what I'm running before every release as a sanity check for 1.3
compatibility.

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Ben Alex
Sent: Wednesday, July 13, 2005 4:49 AM
To: spr...@li...
Cc: ace...@li...
Subject: [Springframework-developer] Spring 1.2 Support for JDK 1.3

Scott McCrory wrote:

>In short, I'd be just a tiny voice asking for Spring 1.2+ to maintain 
>JDK
>1.3 compatability, but is it too late to decouple Acegi from Spring 1.2+?
>  
>
I'll move this to the Spring Developers mailing list, as it's more related
to Spring than Acegi Security. Juergen posted an email in April that gave me
the impression Spring's JDK 1.3 support was pretty good: 
http://thread.gmane.org/gmane.comp.java.springframework.devel/8208. Is this
no longer the case?

We would have a difficult time maintaining support for multiple Spring
versions in Acegi Security. I would prefer to know that Spring 1.2
definitely could not support JDK 1.3 before going down that path.

Cheers
Ben


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Spring 1.2 Support for JDK 1.3

[Ben A. <ben...@ac...>]

Scott McCrory wrote:

>In short, I'd be just a tiny voice asking for Spring 1.2+ to maintain JDK 
>1.3 compatability, but is it too late to decouple Acegi from Spring 1.2+?
>  
>
I'll move this to the Spring Developers mailing list, as it's more 
related to Spring than Acegi Security. Juergen posted an email in April 
that gave me the impression Spring's JDK 1.3 support was pretty good: 
http://thread.gmane.org/gmane.comp.java.springframework.devel/8208. Is 
this no longer the case?

We would have a difficult time maintaining support for multiple Spring 
versions in Acegi Security. I would prefer to know that Spring 1.2 
definitely could not support JDK 1.3 before going down that path.

Cheers
Ben

[Springframework-developer] spring build.304 Build Successful

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

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

Re: [Springframework-developer] old dependencies on spring portlet in webflow

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

We are currently leaning towards releasing the Portlet support in an =
earlier
1.3 release candidate by the end of July, with a quick 1.2.3 release
inbetween (early next week). Web Flow RC1 will then build on Spring 1.3 =
RC1.

Shipping mock objects for the Portlet API is certainly valuable - thanks =
for
pointing this out! I envision a set of mock objects analogous to our
existing Servlet API mocks, to be included in spring-mock.jar. We should
certainly provide this in Spring 1.3 RC1.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Yujin Kim
Sent: Friday, July 08, 2005 8:27 PM
To: spr...@li...
Subject: Re: [Springframework-developer] old dependencies on spring =
portlet
in webflow

Not knowing what's in the scope for 1.2.3, I'd also like to mention that
current versions(both sandbox and john's versions) lacks the unit =
testing
capabilities.  I did create some really basic mock objects for portet
request and response, but it would be great if some testing capabilities =
are
included in 1.2.3 or 1.2.4 (not sure what you have in mind after 1.2.3).

john and some of us also have exchanged emails regarding how to map the
controllers based on both state (as in portlet mode) as well as custom
parameters using nested map.  While we both have somewhat functional
version, i think it's one of the areas that might require a
bit of discussion.   I haven't even started mapping the window state
in the mix yet.  so that could potentially add a little bit more =
elements to
it.  Probably this is where WebFlow could help a lot I am guessing.

Yujin

On 7/8/05, Juergen Hoeller <ju...@in...> wrote:
> No worries, that's already in the works :-)
>=20
> It's one of the things I personally wanted to see changed before the=20
> move into the core.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On=20
> Behalf Of Cris J. Holdorph
> Sent: Thursday, July 07, 2005 5:43 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] old dependencies on spring=20
> portlet in webflow
>=20
> Can we PLEASE PLEASE consider changing the two "handleRequest" methods =

> to different names?  This is a violation of what is consider good=20
> practice for overriding.  They are fundamentally different methods.
> This change REALLY should be made before it is moved into the core.
>=20
> ---- Cris J H
>=20
> Juergen Hoeller wrote:
> > Hi Tim.
> >
> > We actually intend to release the core Portlet support earlier now:=20
> > as part of Spring 1.2.3 in about two weeks. Web Flow RC1 will in=20
> > turn build on that release then.
> >
> > For the meantime, there might be a Web Flow PR4 as a remedy for the=20
> > current situation, but that's up to Keith and Erwin to decide. Else, =

> > I would recommend to continue using Web Flow PR3 on Spring 1.2.1 for =

> > the time being.
> >
> > Juergen
> >
> >
> > --------------------------------------------------------------------
> > --
> > --
> > *From:* spr...@li...
> > [mailto:spr...@li...] *On=20
> > Behalf Of *Tim Kettering
> > *Sent:* Wednesday, July 06, 2005 7:56 PM
> > *To:* spr...@li...
> > *Subject:* [Springframework-developer] old dependencies on spring=20
> > portlet in webflow
> >
> >
> >
> > This really addresses two issues I'm having w/ spring portlet=20
> > development.  I am attempting to use spring webflow /w the portlets, =

> > and the PR3 release of webflow apparently includes references to=20
> > older versions of portlet code (that exist in the spring sandbox) -=20
> > and the latest version of spring-portlets as released by john lewis=20
> > includes significantly updated code, and when attempting to include=20
> > all those jars in the portlet environment, theres all sorts of=20
> > classloader issues w/ different versions of DispatchPortlet and=20
> > PortletController lying around.  I've been trying to rebuild parts=20
> > to get them all to talk to each other, but it's been a big =
time-sink.
> >
> >
> >
> > I see the best solution being that John being allowed to merge his=20
> > portlet code in the cvs - so that webflow can be coded against the=20
> > proper classes and those classes being dropped from webflow-support.
> > I know that this has been under discussion lately to start with 1.3=20
> > development, and I'm hoping with the release of 1.2.2 complete, that =

> > things can move in that direction.
> >
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies =

> from IBM. Find simple to follow Roadmaps, straightforward articles,=20
> informative Webcasts and more! Get everything you need to get up to =
speed,
fast.
> http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar=20
> happening July 14 at 8am PDT/11am EDT. We invite you to explore the=20
> latest in dual core and dual graphics technology at this free one hour =

> event hosted by HP, AMD, and NVIDIA.  To register visit=20
> http://www.hp.com/go/dualwebinar=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar =
happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by =
HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Security advisory for all Acegi Security users

[Ben A. <ben...@ac...>]

Dear Spring Community

A potentially serious bug has been identified in existing releases of 
Acegi Security 
(http://opensource.atlassian.com/projects/spring/browse/SEC-20). New and 
supported releases (0.7.1 and 0.8.3) are now available that correct this 
issue. We urge all users to upgrade as soon as possible:

* Users of CVS HEAD should rebuild from the current CVS HEAD
* Users of releases 0.8.0, 0.8.1 or 0.8.2 should upgrade to release 0.8.3
* Users of release 0.7.0 should upgrade to release 0.7.1, or preferably 
release 0.8.3
* Users of releases prior to 0.7.0 should upgrade to 0.7.1, or 
preferably release 0.8.3

You can download these releases directly from 
https://sourceforge.net/project/showfiles.php?group_id=104215.

If anyone has any questions, please email the acegisecuity-developer 
mailing list.

Cheers
Ben

Re: [Springframework-developer] Re: old dependencies on spring portlet in webflow

[Yujin K. <net...@gm...>]

Just being able to work off of stock spring jar will make us happy. :-)
also if you guys need anything, Tim (Kettering) and I are here to
offer our assistance.

Yujin

On 7/11/05, Juergen Hoeller <ju...@in...> wrote:
> BTW, we are currently leaning towards releasing the Portlet support in an
> earlier 1.3 release candidate by the end of July, with a quick 1.2.3 rele=
ase
> inbetween. Web Flow RC1 will then build on Spring 1.3 RC1.
>=20
> I'll announce a concrete roadmap as soon as everything's settled.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf =
Of
> John Lewis
> Sent: Monday, July 11, 2005 11:04 PM
> To: spr...@li...
> Subject: [Springframework-developer] Re: old dependencies on spring portl=
et
> in webflow
>=20
> FYI: I am going to release some major changes to the Portlet MVC code,
> hopefully later today.  These are changes that Juergen and I discussed in
> preparation for merging it into the core Spring codebase for 1.2.3.
> Some of the changes are disruptive and will require some adjustments to c=
ode
> that uses the current classes.
>=20
> John
>=20
>=20
> Keith Donald wrote:
> > Erwin and I are working on the release now.
> >
> > Expect an announcement later today or tomorrow.
> >
> > Keith
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On
> > Behalf Of Scott Battaglia
> > Sent: Monday, July 11, 2005 1:46 PM
> > To: spr...@li...
> > Subject: Re: [Springframework-developer] old dependencies on spring
> > portlet in webflow
> >
> > Erwin,
> >
> > Do you have an idea on when PR4 will be released? I'm hoping to
> > release a new version of CAS soon with Spring 1.2.2 as a dependency
> > but PR3 doesn't work with it :-) I'm wondering whether I should wait
> > for PR4 or rollback to Spring 1.2.1 for the time being.
> >
> > Thanks!
> > -Scott
> >
> > Scott Battaglia
> > Application Developer, Architecture & Engineering Group Enterprise
> > Systems and Services, Rutgers University
> > v: 732.445.0097 | f: 732.445.5493 | sco...@ru...
> >
> >
> >
> > Erwin Vervaet wrote:
> >
> >
> >>Yes, this is an urgent issue.
> >>There are also other conflicts between SWF PR3 and Spring 1.2.2. Keith
> >>and I are working on releasing a PR4 release ASAP to address these
> >>classpath conflicts.
> >>Erwin Vervaet
> >>erw...@er... <mailto:erw...@er...>
> >>
> >>    ----- Original Message -----
> >>    *From:* Tim Kettering <mailto:tim...@vi...>
> >>    *To:* spr...@li...
> >>    <mailto:spr...@li...>
> >>    *Sent:* Wednesday, July 06, 2005 7:56 PM
> >>    *Subject:* [Springframework-developer] old dependencies on spring
> >>    portlet in webflow
> >>
> >>    This really addresses two issues I'm having w/ spring portlet
> >>    development. I am attempting to use spring webflow /w the
> >>    portlets, and the PR3 release of webflow apparently includes
> >>    references to older versions of portlet code (that exist in the
> >>    spring sandbox) - and the latest version of spring-portlets as
> >>    released by john lewis includes significantly updated code, and
> >>    when attempting to include all those jars in the portlet
> >>    environment, theres all sorts of classloader issues w/ different
> >>    versions of DispatchPortlet and PortletController lying around.
> >>    I've been trying to rebuild parts to get them all to talk to each
> >>    other, but it's been a big time-sink.
> >>
> >>    I see the best solution being that John being allowed to merge his
> >>    portlet code in the cvs - so that webflow can be coded against the
> >>    proper classes and those classes being dropped from
> >>    webflow-support. I know that this has been under discussion lately
> >>    to start with 1.3 development, and I'm hoping with the release of
> >>    1.2.2 complete, that things can move in that direction.
> >>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by the 'Do More With Dual!' webinar
> > happening July 14 at 8am PDT/11am EDT. We invite you to explore the
> > latest in dual core and dual graphics technology at this free one hour
> > event hosted by HP, AMD, and NVIDIA.  To register visit
> > http://www.hp.com/go/dualwebinar
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by the 'Do More With Dual!' webinar
> > happening July 14 at 8am PDT/11am EDT. We invite you to explore the
> > latest in dual core and dual graphics technology at this free one hour
> > event hosted by HP, AMD, and NVIDIA.  To register visit
> > http://www.hp.com/go/dualwebinar
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happen=
ing
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by H=
P,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happen=
ing
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by H=
P,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Re: old dependencies on spring portlet in webflow

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

BTW, we are currently leaning towards releasing the Portlet support in an
earlier 1.3 release candidate by the end of July, with a quick 1.2.3 release
inbetween. Web Flow RC1 will then build on Spring 1.3 RC1.

I'll announce a concrete roadmap as soon as everything's settled.

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
John Lewis
Sent: Monday, July 11, 2005 11:04 PM
To: spr...@li...
Subject: [Springframework-developer] Re: old dependencies on spring portlet
in webflow

FYI: I am going to release some major changes to the Portlet MVC code,
hopefully later today.  These are changes that Juergen and I discussed in
preparation for merging it into the core Spring codebase for 1.2.3. 
Some of the changes are disruptive and will require some adjustments to code
that uses the current classes.

John


Keith Donald wrote:
> Erwin and I are working on the release now.
> 
> Expect an announcement later today or tomorrow.
> 
> Keith
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of Scott Battaglia
> Sent: Monday, July 11, 2005 1:46 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] old dependencies on spring 
> portlet in webflow
> 
> Erwin,
> 
> Do you have an idea on when PR4 will be released? I'm hoping to 
> release a new version of CAS soon with Spring 1.2.2 as a dependency 
> but PR3 doesn't work with it :-) I'm wondering whether I should wait 
> for PR4 or rollback to Spring 1.2.1 for the time being.
> 
> Thanks!
> -Scott
> 
> Scott Battaglia
> Application Developer, Architecture & Engineering Group Enterprise 
> Systems and Services, Rutgers University
> v: 732.445.0097 | f: 732.445.5493 | sco...@ru...
> 
> 
> 
> Erwin Vervaet wrote:
> 
> 
>>Yes, this is an urgent issue.
>>There are also other conflicts between SWF PR3 and Spring 1.2.2. Keith 
>>and I are working on releasing a PR4 release ASAP to address these 
>>classpath conflicts.
>>Erwin Vervaet
>>erw...@er... <mailto:erw...@er...>
>>
>>    ----- Original Message -----
>>    *From:* Tim Kettering <mailto:tim...@vi...>
>>    *To:* spr...@li...
>>    <mailto:spr...@li...>
>>    *Sent:* Wednesday, July 06, 2005 7:56 PM
>>    *Subject:* [Springframework-developer] old dependencies on spring
>>    portlet in webflow
>>
>>    This really addresses two issues I'm having w/ spring portlet
>>    development. I am attempting to use spring webflow /w the
>>    portlets, and the PR3 release of webflow apparently includes
>>    references to older versions of portlet code (that exist in the
>>    spring sandbox) - and the latest version of spring-portlets as
>>    released by john lewis includes significantly updated code, and
>>    when attempting to include all those jars in the portlet
>>    environment, theres all sorts of classloader issues w/ different
>>    versions of DispatchPortlet and PortletController lying around.
>>    I've been trying to rebuild parts to get them all to talk to each
>>    other, but it's been a big time-sink.
>>
>>    I see the best solution being that John being allowed to merge his
>>    portlet code in the cvs - so that webflow can be coded against the
>>    proper classes and those classes being dropped from
>>    webflow-support. I know that this has been under discussion lately
>>    to start with 1.3 development, and I'm hoping with the release of
>>    1.2.2 complete, that things can move in that direction.
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar 
> happening July 14 at 8am PDT/11am EDT. We invite you to explore the 
> latest in dual core and dual graphics technology at this free one hour 
> event hosted by HP, AMD, and NVIDIA.  To register visit 
> http://www.hp.com/go/dualwebinar 
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar 
> happening July 14 at 8am PDT/11am EDT. We invite you to explore the 
> latest in dual core and dual graphics technology at this free one hour 
> event hosted by HP, AMD, and NVIDIA.  To register visit 
> http://www.hp.com/go/dualwebinar



-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: old dependencies on spring portlet in webflow

[John L. <jl...@ar...>]

FYI: I am going to release some major changes to the Portlet MVC code, 
hopefully later today.  These are changes that Juergen and I discussed 
in preparation for merging it into the core Spring codebase for 1.2.3. 
Some of the changes are disruptive and will require some adjustments to 
code that uses the current classes.

John


Keith Donald wrote:
> Erwin and I are working on the release now.
> 
> Expect an announcement later today or tomorrow.
> 
> Keith
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf Of
> Scott Battaglia
> Sent: Monday, July 11, 2005 1:46 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] old dependencies on spring portlet
> in webflow
> 
> Erwin,
> 
> Do you have an idea on when PR4 will be released? I'm hoping to release 
> a new version of CAS soon with Spring 1.2.2 as a dependency but PR3 
> doesn't work with it :-) I'm wondering whether I should wait for PR4 or 
> rollback to Spring 1.2.1 for the time being.
> 
> Thanks!
> -Scott
> 
> Scott Battaglia
> Application Developer, Architecture & Engineering Group
> Enterprise Systems and Services, Rutgers University
> v: 732.445.0097 | f: 732.445.5493 | sco...@ru...
> 
> 
> 
> Erwin Vervaet wrote:
> 
> 
>>Yes, this is an urgent issue.
>>There are also other conflicts between SWF PR3 and Spring 1.2.2. Keith 
>>and I are working on releasing a PR4 release ASAP to address these 
>>classpath conflicts.
>>Erwin Vervaet
>>erw...@er... <mailto:erw...@er...>
>>
>>    ----- Original Message -----
>>    *From:* Tim Kettering <mailto:tim...@vi...>
>>    *To:* spr...@li...
>>    <mailto:spr...@li...>
>>    *Sent:* Wednesday, July 06, 2005 7:56 PM
>>    *Subject:* [Springframework-developer] old dependencies on spring
>>    portlet in webflow
>>
>>    This really addresses two issues I'm having w/ spring portlet
>>    development. I am attempting to use spring webflow /w the
>>    portlets, and the PR3 release of webflow apparently includes
>>    references to older versions of portlet code (that exist in the
>>    spring sandbox) - and the latest version of spring-portlets as
>>    released by john lewis includes significantly updated code, and
>>    when attempting to include all those jars in the portlet
>>    environment, theres all sorts of classloader issues w/ different
>>    versions of DispatchPortlet and PortletController lying around.
>>    I've been trying to rebuild parts to get them all to talk to each
>>    other, but it's been a big time-sink.
>>
>>    I see the best solution being that John being allowed to merge his
>>    portlet code in the cvs - so that webflow can be coded against the
>>    proper classes and those classes being dropped from
>>    webflow-support. I know that this has been under discussion lately
>>    to start with 1.3 development, and I'm hoping with the release of
>>    1.2.2 complete, that things can move in that direction.
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by HP,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by HP,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

Re: [Springframework-developer] Beans with factory-method treated like FactoryBeans

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

Some more on this:
  http://forum.springframework.org/viewtopic.php?p=27219#27219


Juergen Hoeller wrote:

>Finally committed.
>
>(It's a busy weekend here: entire apartment freshly painted.)
>
>Juergen
> 
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Juergen Hoeller
>Sent: Sunday, July 10, 2005 9:37 AM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Beans with factory-method treated
>like FactoryBeans
>
>Hi Colin,
>
>Thanks for your feedback. There have indeed been some tricky issues in the
>factory method handling, mainly in determining the type upfront. Pre 1.2.2
>we simply considered the type undeterminable for all factory methods.
>
>In 1.2.2, we try to figure it out as far as possible, which unfortunately
>led to a potential side effect with too early creation of "factory-bean"
>targets - even before BeanFactoryPostProcessors. This led to the refinement
>that a "factory-method" will only be resolved if the "includeFactoryBeans"
>flag is "true" - which it isn't for BeanFactoryPostProcessors.
>
>You got a point there in that this should only apply to actual
>"factory-bean" references. For a static "factory-method" on the given class,
>we should try to figure out the type statically - as far as possible, even
>with "includeFactoryBeans" being "false". If a bean instance is already
>created, we'll always return the actual type anyway.
>
>I've just refined this accordingly, through only excluding "factory-bean"
>references if "includeFactoryBeans" is off. To figure out the type for a
>factory method, AbstractBeanFactory's "getType" delegates to the newly
>introduced "getTypeForFactoryMethod" now, which creates the object in case
>of a "factory-bean" reference (if appropriate) or checks the return type of
>the static factory method else.
>
>However, we can only clearly determine the type if we either only have a
>single static factory method of the given name or multiple overloaded
>factory methods that all return the same type (there's hardly gonna be any
>other case). Else, we'll return null as "undeterminable" upfront: The actual
>factory method called will only be clear after converting constructor
>arguments and/or autowiring.
>
>Juergen
> 
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Colin Sampaleanu
>Sent: Saturday, July 09, 2005 6:42 PM
>To: spr...@li...
>Subject: [Springframework-developer] Beans with factory-method treated like
>FactoryBeans
>
>Juergen,
>
>I saw you made some changes for how beans with factory-method set are
>treated, so that they are essentially treated closer to being a FactoryBean
>in some respects. I don't necessarilly disagree or anything (and it looks
>like there were some bugs too, in any case), but I'm trying to see the
>rationale for the changes.
>
>- for 1.2.2 in DefaultListableBeanFactory, there is a comment:
>   "* exclude bean definitions with factory method from pre-instantiation
>type matching; pre-instantiate and match beans with factory method /
>"factory-bean" definition".
>- post 1.2.2, there is a comment:
>  "DefaultListableBeanFactory does not create beans with "factory-method"
>for type check if "includeFactoryBeans"=false"
>
>As I see the current code, beans with a factory method get treated
>essentially the same as a FactoryBean. getBeanNamesForType will now only
>match the result of a bean def with a factory-method set if the
>'includeFactoryBeans' arg is set to true, and to get this to happen, the
>bean will actually always be created (via a getBean).
>
>But unless I'm missing something, I think this might be the wrong behaviour
>for static factroy methods. The factory class is known, as well as the
>static factory method with the proper return type. The match can be done
>properly without ever creating the bean. In this respect, I see the static
>factory method being a direct alternative to new/newInstance().
>
>Now a non-static factory method (via a sibling factory-bean ref) is I guess
>a different thing. You could even handle some of those statically if you
>look at the actual factory-bean referenced, and it's just a normal bean, and
>the method declares the return type. But certainly if the referenced
>factory-bean is a FactoryBean itself that's not going to work. So for the
>non-static case I guess it makes sense to keep the bean def with a
>factory-bean ref treated just like a FactoryBean; it's simpler and more
>deterministic.
>
>What do you think / can you clarify?
>
>Colin
>
>--
>Colin Sampaleanu
>Interface21 Principal Consultant
>Spring Training, Consulting and Support - "From the Source"
>http://www.springframework.com
>
>  
>

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

RE: [Springframework-developer] old dependencies on spring portlet in webflow

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

Erwin and I are working on the release now.

Expect an announcement later today or tomorrow.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Scott Battaglia
Sent: Monday, July 11, 2005 1:46 PM
To: spr...@li...
Subject: Re: [Springframework-developer] old dependencies on spring portlet
in webflow

Erwin,

Do you have an idea on when PR4 will be released? I'm hoping to release 
a new version of CAS soon with Spring 1.2.2 as a dependency but PR3 
doesn't work with it :-) I'm wondering whether I should wait for PR4 or 
rollback to Spring 1.2.1 for the time being.

Thanks!
-Scott

Scott Battaglia
Application Developer, Architecture & Engineering Group
Enterprise Systems and Services, Rutgers University
v: 732.445.0097 | f: 732.445.5493 | sco...@ru...



Erwin Vervaet wrote:

> Yes, this is an urgent issue.
> There are also other conflicts between SWF PR3 and Spring 1.2.2. Keith 
> and I are working on releasing a PR4 release ASAP to address these 
> classpath conflicts.
> Erwin Vervaet
> erw...@er... <mailto:erw...@er...>
>
>     ----- Original Message -----
>     *From:* Tim Kettering <mailto:tim...@vi...>
>     *To:* spr...@li...
>     <mailto:spr...@li...>
>     *Sent:* Wednesday, July 06, 2005 7:56 PM
>     *Subject:* [Springframework-developer] old dependencies on spring
>     portlet in webflow
>
>     This really addresses two issues I'm having w/ spring portlet
>     development. I am attempting to use spring webflow /w the
>     portlets, and the PR3 release of webflow apparently includes
>     references to older versions of portlet code (that exist in the
>     spring sandbox) - and the latest version of spring-portlets as
>     released by john lewis includes significantly updated code, and
>     when attempting to include all those jars in the portlet
>     environment, theres all sorts of classloader issues w/ different
>     versions of DispatchPortlet and PortletController lying around.
>     I've been trying to rebuild parts to get them all to talk to each
>     other, but it's been a big time-sink.
>
>     I see the best solution being that John being allowed to merge his
>     portlet code in the cvs - so that webflow can be coded against the
>     proper classes and those classes being dropped from
>     webflow-support. I know that this has been under discussion lately
>     to start with 1.3 development, and I'm hoping with the release of
>     1.2.2 complete, that things can move in that direction.
>


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] old dependencies on spring portlet in webflow

[Scott B. <sco...@ru...>]

Erwin,

Do you have an idea on when PR4 will be released? I'm hoping to release=20
a new version of CAS soon with Spring 1.2.2 as a dependency but PR3=20
doesn't work with it :-) I'm wondering whether I should wait for PR4 or=20
rollback to Spring 1.2.1 for the time being.

Thanks!
-Scott

Scott Battaglia
Application Developer, Architecture & Engineering Group
Enterprise Systems and Services, Rutgers University
v: 732.445.0097 | f: 732.445.5493 | sco...@ru...



Erwin Vervaet wrote:

> Yes, this is an urgent issue.
> There are also other conflicts between SWF PR3 and Spring 1.2.2. Keith=20
> and I are working on releasing a PR4 release ASAP to address these=20
> classpath conflicts.
> Erwin Vervaet
> erw...@er... <mailto:erw...@er...>
>
>     ----- Original Message -----
>     *From:* Tim Kettering <mailto:tim...@vi...>
>     *To:* spr...@li...
>     <mailto:spr...@li...>
>     *Sent:* Wednesday, July 06, 2005 7:56 PM
>     *Subject:* [Springframework-developer] old dependencies on spring
>     portlet in webflow
>
>     This really addresses two issues I=92m having w/ spring portlet
>     development. I am attempting to use spring webflow /w the
>     portlets, and the PR3 release of webflow apparently includes
>     references to older versions of portlet code (that exist in the
>     spring sandbox) =96 and the latest version of spring-portlets as
>     released by john lewis includes significantly updated code, and
>     when attempting to include all those jars in the portlet
>     environment, theres all sorts of classloader issues w/ different
>     versions of DispatchPortlet and PortletController lying around.
>     I=92ve been trying to rebuild parts to get them all to talk to each
>     other, but it=92s been a big time-sink.
>
>     I see the best solution being that John being allowed to merge his
>     portlet code in the cvs =96 so that webflow can be coded against th=
e
>     proper classes and those classes being dropped from
>     webflow-support. I know that this has been under discussion lately
>     to start with 1.3 development, and I=92m hoping with the release of
>     1.2.2 complete, that things can move in that direction.
>

[Springframework-developer] $B:#J?5$$G$9$+!)(B

[<in...@my...>]

$B%i%V!&%G!&%.%c%k%=%s!!4IM}2]$NEOJU$G$9!#(B
$BEbFM$N%a!<%k!"?=$7Lu$"$j$^$;$s$,!"$4M}2r$r$*4j$$$7$^$9!#(B

$BEv%5%$%H$N#V#I#P=w@-2q0w(B[$B-b(B112070]$BNC;RMM$+$i5.J}08$K0MMj%a!<%k(B
$B$,FO$$$F$$$^$9!#%3%A%i$GK\J8$rE:IU$7$FG[?.$5$;$FD:$-$^$7$?!#(B
$BLBOG$G$7$?$i!"$*OM$S$5$;$FD:$-$^$9!#(B

$B!X!!FMA3$N%a!<%k$G?=$7Lu$"$j$^$;$s!#(B
$B!!4JC1$K$G$9$,<+8J>R2p$r$5$;$FD:$-$^$9!#(B
$B!!H~MF<<7P1D$r$7$F$$$^$9!#(B5$BG/4VDx7k:'$7$F$$$?$s$G$9$,!";E;v$N(B
$B!!ET9g$G$9$l0c$$$N@83h$,B3$-N%:'$7$F$7$^$$$^$7$?!#(B35$B:P$N;d$,(B
$B!!Aj8_$NM}2r$,$"$kBg?M$N8r:]$r5a$a$F$$$^$9!#(B
$B!!$*6b$O;d$NM_$rK~$?$7$FD:$/0Y$N<UNi$H9M$($F$$$?$@$1$l$P7k9=(B
$B!!$G$9!#IT:Y9)$J=w$G$O$J$$$N$G(B($BH~MF<<7P1D(B)$B!"IT0B$@$C$?$i<L??(B
$B!!8x3+$7$F$$$^$9$N$G!#(B
$B!!;d$N?4$H?HBN$N7d4V$rKd$a$F$b$i$($^$9$G$7$g$&$+!)(B
$B!!Fq$7$$;v$O8@$$$^$;$s!*JV;v$r$$$?$@$1$?$iD>@\%a!<%k$7$^$9!#(B
$B!!4JC1$G$$$$$N$G!"5.J}MM$N<+8J>R2p$rE:$($F$*JV;v$$$?$@$1$^$;(B
$B!!$s$G$7$g$&$+!)(B
$B!!2w$$JV;v$,$"$k;v$r$*BT$A$7$F$*$j$^$9!#!Y(B

$B"!!Z=w@->pJs4IM}![%Z!<%8$O$3$A$i(B
   http://www.lovegal2.net?ryouko

$B1\Mw%Q%9%o!<%I!Z(B4649$B![(B($B$h!&$m!&$7!&$/(B)

$B"($3$N%Q%9%o!<%I$r%K%C%/%M!<%`$N:G8e$KDI2C$7$FEPO?(B($BL5NA(B)$B$7$F(B
$BD:$/$H!";XL>>ZL@$H$J$j$^$9!#(B
$B99$KEPO?CO0h$N=w@-2q0w$+$iD>%a!<%k$,FO$-$^$9!#K:$l$J$$$h$&$*(B
$B4j$$$7$^$9!#(B
$B"(;XL>$5$l$?J}$O-dG'>Z$r9T$&$H$J$s$H!zAm3[(B10,000$B1_J,!z$N%]%$(B
$B%s%H$,40A4L5NA$GDI2C$5$;$FD:$-$^$9!#(B



------------------------------------------------------------
$B$*<j?t$G$9$,G[?.5qH]$NJ}$O%3%A%i$^$G(B no...@lo...

Re: [Springframework-developer] old dependencies on spring portlet in webflow

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

FYI, we are currently debating what goes into Spring 1.2.3 / 1.3 RC1, and
the exact timeline in conjunction with Web Flow. Please stay tuned :-)
 
What I can promise already is that there definitely will be a supported
Spring core / Web Flow combo which includes Portlet support by the end of
July (at least as release candidate).
 
Juergen
 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Tim Kettering
Sent: Monday, July 11, 2005 5:53 PM
To: spr...@li...
Subject: RE: [Springframework-developer] old dependencies on spring portlet
in webflow



 

Hi Erwin,

 

Can you give a little more information about the timeline (at least how you
see it) for the SWF 1.0 / 1.2.3 release.  We are trying to set up some
priorities here in-house and we are hoping to use spring, portlets and SWF.
it is my understanding that 1.2.3 is due for a release next week.  Are you
anticipating on releasing SWF 1.0 at around the same time?  Is there
anything I can do to help with this?

 

-tim

 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Erwin Vervaet
Sent: Friday, July 08, 2005 2:46 AM
To: spr...@li...
Subject: Re: [Springframework-developer] old dependencies on spring portlet
in webflow

 

We're going for a SWF PR4 release which will temporarily drop Portlet
support but will work correctly on top of Spring 1.2.2. A SWF 1.0 release on
top of Spring 1.2.3 with full Potlet support will follow shortly, as Juergen
indicates.

 

Erwin Vervaet
erw...@er...

----- Original Message ----- 

From: Juergen  <mailto:ju...@in...> Hoeller 

To: spr...@li... 

Sent: Thursday, July 07, 2005 12:41 PM

Subject: Re: [Springframework-developer] old dependencies on spring portlet
in webflow

 

Hi Tim.

 

We actually intend to release the core Portlet support earlier now: as part
of Spring 1.2.3 in about two weeks. Web Flow RC1 will in turn build on that
release then.

 

For the meantime, there might be a Web Flow PR4 as a remedy for the current
situation, but that's up to Keith and Erwin to decide. Else, I would
recommend to continue using Web Flow PR3 on Spring 1.2.1 for the time being.

 

Juergen

 

 


  _____  


From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Tim Kettering
Sent: Wednesday, July 06, 2005 7:56 PM
To: spr...@li...
Subject: [Springframework-developer] old dependencies on spring portlet in
webflow

 

This really addresses two issues I'm having w/ spring portlet development.
I am attempting to use spring webflow /w the portlets, and the PR3 release
of webflow apparently includes references to older versions of portlet code
(that exist in the spring sandbox) - and the latest version of
spring-portlets as released by john lewis includes significantly updated
code, and when attempting to include all those jars in the portlet
environment, theres all sorts of classloader issues w/ different versions of
DispatchPortlet and PortletController lying around.  I've been trying to
rebuild parts to get them all to talk to each other, but it's been a big
time-sink.

 

I see the best solution being that John being allowed to merge his portlet
code in the cvs - so that webflow can be coded against the proper classes
and those classes being dropped from webflow-support.  I know that this has
been under discussion lately to start with 1.3 development, and I'm hoping
with the release of 1.2.2 complete, that things can move in that direction.

RE: [Springframework-developer] old dependencies on spring portlet in webflow

[Tim K. <tim...@vi...>]

 

Hi Erwin,

 

Can you give a little more information about the timeline (at least how you
see it) for the SWF 1.0 / 1.2.3 release.  We are trying to set up some
priorities here in-house and we are hoping to use spring, portlets and SWF.
it is my understanding that 1.2.3 is due for a release next week.  Are you
anticipating on releasing SWF 1.0 at around the same time?  Is there
anything I can do to help with this?

 

-tim

 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Erwin Vervaet
Sent: Friday, July 08, 2005 2:46 AM
To: spr...@li...
Subject: Re: [Springframework-developer] old dependencies on spring portlet
in webflow

 

We're going for a SWF PR4 release which will temporarily drop Portlet
support but will work correctly on top of Spring 1.2.2. A SWF 1.0 release on
top of Spring 1.2.3 with full Potlet support will follow shortly, as Juergen
indicates.

 

Erwin Vervaet
erw...@er...

----- Original Message ----- 

From: Juergen <mailto:ju...@in...>  Hoeller 

To: spr...@li... 

Sent: Thursday, July 07, 2005 12:41 PM

Subject: Re: [Springframework-developer] old dependencies on spring portlet
in webflow

 

Hi Tim.

 

We actually intend to release the core Portlet support earlier now: as part
of Spring 1.2.3 in about two weeks. Web Flow RC1 will in turn build on that
release then.

 

For the meantime, there might be a Web Flow PR4 as a remedy for the current
situation, but that's up to Keith and Erwin to decide. Else, I would
recommend to continue using Web Flow PR3 on Spring 1.2.1 for the time being.

 

Juergen

 

 


  _____  


From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Tim Kettering
Sent: Wednesday, July 06, 2005 7:56 PM
To: spr...@li...
Subject: [Springframework-developer] old dependencies on spring portlet in
webflow

 

This really addresses two issues I'm having w/ spring portlet development.
I am attempting to use spring webflow /w the portlets, and the PR3 release
of webflow apparently includes references to older versions of portlet code
(that exist in the spring sandbox) - and the latest version of
spring-portlets as released by john lewis includes significantly updated
code, and when attempting to include all those jars in the portlet
environment, theres all sorts of classloader issues w/ different versions of
DispatchPortlet and PortletController lying around.  I've been trying to
rebuild parts to get them all to talk to each other, but it's been a big
time-sink.

 

I see the best solution being that John being allowed to merge his portlet
code in the cvs - so that webflow can be coded against the proper classes
and those classes being dropped from webflow-support.  I know that this has
been under discussion lately to start with 1.3 development, and I'm hoping
with the release of 1.2.2 complete, that things can move in that direction.

Re: [Springframework-developer] Re: SWF: double _eventId syndrome

[Steven D. <ste...@gm...>]

Keith,

Great, thanks for the feedback.

Steven

On 7/11/05, Keith Donald <ke...@in...> wrote:
> Steven,
>=20
> What I always do for forms is this format:
> <input type=3D"text" name=3D"_eventId_submit" value=3D"Submit"/>
> <input type=3D"text" name=3D"_eventId_cancel" value=3D"Cancel"/>
>=20
> That way the eventId is only submitted if the button is pressed.  We shou=
ld
> arguably update the samples to use this format.
>=20
> This situation will be detected on the server-side for PR4 with an
> appropriate error message.
>=20
> Keith
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf =
Of
> Steven Devijver
> Sent: Sunday, July 10, 2005 6:11 PM
> To: spr...@li...
> Subject: [Springframework-developer] Re: SWF: double _eventId syndrome
>=20
> And a better exception would be nice as well :-)
>=20
> On 7/11/05, Steven Devijver <ste...@gm...> wrote:
> > Hi,
> >
> > I am faced with the same problem as described in this thread on the for=
um:
> >
> > http://forum.springframework.org/viewtopic.php?t=3D6791&highlight=3Deve=
ntid
> >
> > I go to a detail screen from a table through a link. On the details
> > screen is a form that has a _eventId field. When I submit my browser
> > sends two _eventId request parameters: one from the URI of the
> > previous request and one from the form.
> >
> > The only solution I can think of to solve this problem is to introduce
> > a _formEventId parameter that precedes over _eventId. It's a bit
> > broken since users can use _formEventId in URI as well.
> >
> > Steven
> >
> > --
> > "If you want to be a different fish, you gotta jump out of the school."
> > -- Captain Beefheart
> >
>=20
>=20
> --
> "If you want to be a different fish, you gotta jump out of the school."
> -- Captain Beefheart
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happen=
ing
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by H=
P,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happen=
ing
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by H=
P,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20


--=20
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart

Re: [Springframework-developer] Ivy woes (part 2)

[Steven D. <ste...@gm...>]

Colin,

Thanks for your feedback. I forgot I had an older version on Ivy in my
ant lib folder. It works fine now.

Steven

On 7/10/05, Colin Sampaleanu <col...@ex...> wrote:
> Steven,
>=20
> If you're using ivy 1.0 that's because Ivy 1.0 is installed in your ant
> lib dir. The build right now relies on you to have an up-to-date ivy jar
> in your ant lib dir.
>=20
> Now in fact you need to use a post 1.1 snapshot of ivy. One part of the
> build relies on a bugfix in the publish task as it relates to finding
> the resolved ivy.xml file for what is being published.
>=20
> I've fixed a few other glitches in dependencies in the SWF samples, and
> also put a current snapshot ivy.jar in the static reposiroty. You should
> check out spring-projects again, and grab the ivy-20050708173612.jar
> from the jayasoft/ivy/jars dir, and drop it into your ant lib dir.
>=20
> One other problem is that we again seem to have a CVS problem with
> trying to check in the right spring-context-1.2.2.jar file ("cvs:
> hash.c:317: findnode: Assertion `key !=3D ((void *)0)' failed."). I need
> to raise a support issue with SF about this. Until then, you're going to
> have to manually get spring-context.jar from the Spring 1.2.2 distro,
> and drop it in the static repo as
>    repository/springframework/spring-context/jars/spring-context-1.2.2.ja=
r
>=20
> This should get you going.
>=20
> Regards,
> Colin
>=20
>=20
> Steven Devijver wrote:
>=20
> >Colin,
> >
> >I've checked out spring-projects but when I do "ant publish" in
> >spring-binding Ivy throws an exception:
> >
> >ivy.configure:
> >     [echo] reading ivy config
> >:: Ivy 1.0 - 20050427114850 :: http://ivy.jayasoft.org/ ::
> >
> >resolve.pre:
> >
> >resolve.main:
> >[resolve.conf] exception while parsing: invalid version 1.1 in
> >file:/Users/stevendevijver/download/spring-projects/spring-binding/ivy.x=
ml
> >
> >BUILD FAILED
> >/Users/stevendevijver/download/spring-projects/common-build/common-targe=
ts.xml:329:
> >syntax errors in ivy file
> >
> >
> >Apparently Ivy 1.0 is being used and the config file indeed is version 1=
.1.
> >
> >Steven
> >
> >
> >
>=20
>=20
> --
> Colin Sampaleanu
> Interface21 Principal Consultant
> Spring Training, Consulting and Support - "From the Source"
> http://www.springframework.com
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happen=
ing
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by H=
P,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20


--=20
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart

RE: [Springframework-developer] Re: SWF: double _eventId syndrome

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

Steven,

What I always do for forms is this format:
<input type="text" name="_eventId_submit" value="Submit"/>
<input type="text" name="_eventId_cancel" value="Cancel"/>

That way the eventId is only submitted if the button is pressed.  We should
arguably update the samples to use this format.

This situation will be detected on the server-side for PR4 with an
appropriate error message.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Steven Devijver
Sent: Sunday, July 10, 2005 6:11 PM
To: spr...@li...
Subject: [Springframework-developer] Re: SWF: double _eventId syndrome

And a better exception would be nice as well :-)

On 7/11/05, Steven Devijver <ste...@gm...> wrote:
> Hi,
> 
> I am faced with the same problem as described in this thread on the forum:
> 
> http://forum.springframework.org/viewtopic.php?t=6791&highlight=eventid
> 
> I go to a detail screen from a table through a link. On the details
> screen is a form that has a _eventId field. When I submit my browser
> sends two _eventId request parameters: one from the URI of the
> previous request and one from the form.
> 
> The only solution I can think of to solve this problem is to introduce
> a _formEventId parameter that precedes over _eventId. It's a bit
> broken since users can use _formEventId in URI as well.
> 
> Steven
> 
> --
> "If you want to be a different fish, you gotta jump out of the school."
> -- Captain Beefheart
> 


-- 
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Javadoc: HibernateTransactionManager

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

True - thanks for spotting this. I'll refine the javadoc accordingly.

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Jon...@o2...
Sent: Monday, July 11, 2005 1:06 PM
To: spr...@li...
Subject: [Springframework-developer] Javadoc: HibernateTransactionManager

 * <p>Supports custom isolation levels, and timeouts that get applied as
appropriate
 * Hibernate query timeouts. To support the latter, application code must
either use
 * one of the <code>HibernateTemplate.find</code> methods or call
 * <code>SessionFactoryUtils.applyTransactionTimeout</code> for each created
 * Hibernate Query object.

From what I think, SessionFactoryUtils.applyTransactionTimeout must only be
called when exposeNativeSession is true (unless using
HibernateTemplate.find). Otherwise session proxy will be created and
CloseSuppressingInvocationHandler will prepare any Query or Criteria object
created from that session just fine. This is a cool feature, so maybe
javadoc should be more detailed here? I was already seeing myself going
through various DAOs and adopting each and every method just because I want
to introduce connection timeouts...

Regards,
Jonas



-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Javadoc: HibernateTransactionManager

[<Jon...@o2...>]

 * <p>Supports custom isolation levels, and timeouts that get applied as 
appropriate
 * Hibernate query timeouts. To support the latter, application code must 
either use
 * one of the <code>HibernateTemplate.find</code> methods or call
 * <code>SessionFactoryUtils.applyTransactionTimeout</code> for each 
created
 * Hibernate Query object.

From what I think, SessionFactoryUtils.applyTransactionTimeout must only 
be called when exposeNativeSession is true (unless using 
HibernateTemplate.find). Otherwise session proxy will be created and 
CloseSuppressingInvocationHandler will prepare any Query or Criteria 
object created from that session just fine. This is a cool feature, so 
maybe javadoc should be more detailed here? I was already seeing myself 
going through various DAOs and adopting each and every method just because 
I want to introduce connection timeouts...

Regards,
Jonas

[Springframework-developer] spring build.303 Build Successful

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

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

[Springframework-developer] Re: SWF: double _eventId syndrome

[Steven D. <ste...@gm...>]

And a better exception would be nice as well :-)

On 7/11/05, Steven Devijver <ste...@gm...> wrote:
> Hi,
>=20
> I am faced with the same problem as described in this thread on the forum=
:
>=20
> http://forum.springframework.org/viewtopic.php?t=3D6791&highlight=3Devent=
id
>=20
> I go to a detail screen from a table through a link. On the details
> screen is a form that has a _eventId field. When I submit my browser
> sends two _eventId request parameters: one from the URI of the
> previous request and one from the form.
>=20
> The only solution I can think of to solve this problem is to introduce
> a _formEventId parameter that precedes over _eventId. It's a bit
> broken since users can use _formEventId in URI as well.
>=20
> Steven
>=20
> --
> "If you want to be a different fish, you gotta jump out of the school."
> -- Captain Beefheart
>=20


--=20
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart