|
From: Mark P. <mar...@sp...> - 2007-12-03 16:33:17
|
Great, I'll check out the latest and give it a whirl. I'll also take a look at PageHandlerFactoryTests.TransferAfterSetResult but 'like a blind man in an orgy I am going to have to feel my way around' Aleks, can you take a quick look? Cheers, Mark -----Original Message----- From: Erich Eichinger [mailto:E.E...@di...] Sent: Monday, December 03, 2007 11:27 AM To: Mark Pollack; Aleksandar Seovic; Bruno Baia; springnet-developer Subject: New "NUnitAspEx" - added real HttpRuntime web test support (was: Server.Transfer() issue) hi, I just committed the test stuff including new support for "integrated HttpRuntime" testing, aka "NUnitAspEx". For now, the sources of our NAnt.NUnit2OutProc.Task and the NUnitAspEx library can be found at https://testingaspnet.googlecode.com/svn/trunk Please give it a try and let me know, if there are any issues. If everything goes well, I'll tag the project(s) accordingly in google-svn for the spring release. ad "NUnitAspEx": Given the most recent TestDriven.NET version, the [AspTestFixture] tests should run from within both vstudios 2k3 & 2k5 as well as from within nant. However it does *not* work with Resharper's NUnit support as Resharper obviously uses a lower nunit version. To get an idea on how to write an AspTestFixture, look at Spring.Net\test\Spring\Spring.Web.Tests\Web\Support\PageHandlerFactoryTests. cs and the corresponding testweb in Spring.Net\test\Spring\Spring.Web.Tests\Data\Spring\Web\Support\PageHandlerF actoryTests\* Suprisingly - at least to me - the test w.r.t Server.Transfer()/SPRNET-763 (http://opensource.atlassian.com/projects/spring/browse/SPRNET-763) / "PageHandlerFactoryTests.TransferAfterSetResult") does not produce any problem. If somoneone can spend a few minutes please double-check that I didn't miss something. cheers, Erich > -----Original Message----- > From: Mark Pollack [mailto:mar...@sp...] > Sent: Monday, December 03, 2007 3:19 PM > To: Erich Eichinger; 'Aleksandar Seovic'; 'Bruno Baia' > Subject: RE: Server.Transfer() issue > > Hi, > > Thanks for the big push, and adding the foundation for the > unit tests. We > are in the home stretch after lord knows how long with 1.1. > > All we can do then is to follow up on DI-transfer issue with > the person who > reported it, should additional minor items come up we can > schedule them for > 1.1.1 > > Cheers, > Mark > > > -----Original Message----- > From: Erich Eichinger [mailto:E.E...@di...] > Sent: Sunday, December 02, 2007 11:39 PM > To: Mark Pollack; Aleksandar Seovic; Bruno Baia > Subject: RE: Server.Transfer() issue > > > Hi, > > I spent a couple of a couple of hours on this now. To > automate testing such > stuff, I decided to upgrade my NUnitAspEx framework to NUnit > 2.4.1. I will > commit it tomorrow - there is one minor open issue to solve. > > > Anyway: I cannot confirm the problems w.r.t > Server.Transfer(). Asfaik there > have been 2 types of complaint on the forums: > > 1) A "ViewStateMac Validation" error occured > > This happens, if you do a Server.Transfer() during a Postback and has > nothing to do w/ Spring. This is normal behaviour, because > the second page > (after the Transfer) tries to deserialize the encrypted > ViewState of the > first page. > In this case one must use the @Page directive > "EnableViewStateMac='false'" > > 2) PreviousPage property is not set correctly > > I couldn't reproduce this at all. The PreviousPage property is set as > expected to the reak type of the page (not the proxy) > > > Need a lot of sleep now... > > cheers, > Erich > > > ________________________________ > > From: Mark Pollack [mailto:mar...@sp...] > Sent: Saturday, December 01, 2007 9:09 PM > To: Erich Eichinger; 'Aleksandar Seovic' > Cc: 'Bruno Baia' > Subject: RE: Server.Transfer() issue > > > X-ExchangeSecure-AntiSpam: valid(71) > > Hi, > > > > I don't know the answer, just wanted to kick start the > conversation > again ...aleks any suggestions here > > > > Mark > > > > Issue a) is par for the course.... > > > > > > > > From: Erich Eichinger [mailto:E.E...@di...] > Sent: Wednesday, November 28, 2007 1:31 AM > To: Aleksandar Seovic; Mark Pollack > Cc: Bruno Baia > Subject: RE: Server.Transfer() issue > > > > Hi, > > > > thanks for the response. I'll have a look at that. > > > > The pb w/ populating the PreviousPage property is, that > > > > a) again it needs a reflection hack > > b) when should this be done? I don't think we can > easily set this > property right after calling ProcessRequest() in > PageHandlerFactory.PageHandler.ProcessRequest(). > > > > Is there more about it than Session & Process support? > I don't think > Session support depends on those 2 proxies. But I will > double-check this. > > > > cheers, > > Erich > > > > ________________________________ > > From: Aleksandar Seovic [mailto:al...@s4...] > Sent: Wed 2007-11-28 06:33 > To: 'Mark Pollack'; Erich Eichinger > Cc: 'Bruno Baia' > Subject: RE: Server.Transfer() issue > > Actually, those proxies are necessary for a number of > things to work > and > have been around from the very beginning. The process stuff was > added to > them way later (and should probably be taken out and handled > differently). > > The main reason for the proxies, if I remember > correctly, is that > without > them your pages lose HTTP session information. > > It's been a while, so I can't exactly remember why this > is the case, > but I > do remember that they were needed to support proper > session behavior > and > cannot be taken out that easily. > > Isn't there a way to retrieve the appropriate value and populate > PreviousPage property on the Spring-managed page within those > proxies. > Actually, I things there should already be some code in > there that > deals > with that... > > - Aleks > > -----Original Message----- > From: Mark Pollack [mailto:mar...@sp...] > Sent: Wednesday, November 28, 2007 12:04 AM > To: 'Erich Eichinger' > Cc: 'Bruno Baia'; 'Aleksandar Seovic' > Subject: RE: Server.Transfer() issue > > Adding 'da-man' into the discussion.... > > > http://opensource.atlassian.com/projects/spring/browse/SPRNET-763 > > We can't go with option 1) since to me that sounds like we are > leaving the > result-set mapping functionality broken. > > Any comments on option #2 aleks? > > > Mark > > -----Original Message----- > From: Erich Eichinger [mailto:E.E...@di...] > Sent: Tuesday, November 27, 2007 5:57 PM > To: Mark Pollack > Cc: Bruno Baia > Subject: Server.Transfer() issue > > > yet another decision request: > > I investigated the issue of Server.Transfer() causing > troubles when > being > used in Postback-scenarios. I guess I found the reason: > Spring.Web's PageHandlerFactory.GetHandler() method > doesn't return > the > requested page instance but a proxy (classes > PageHandler/SessionAwarePageHandler). During > Server.Transfer(), the > output > of GetHandler() is pushed onto a pageHandlerStack, which - among > others - is > used to determine the "PreviousPage" property. Of course in this > case > "PreviousPage" doesn't return an instance of the user's > page, but > Spring's > proxy page instance. > > To solve those problems I expect it to be necessary to > remove those > proxies. > Aleks' introduced them for supporting the IProcess > infrastructure, > thus I > think we can safely remove them. Atm they are causing > more troubles > than > they solve. > > Question - if I don't find another workaround for this issue: > > 1) File it in the release's readme under "Know issues" > > or > > 2) remove the proxy classes and risk introducing other bugs > > > your choice? > > -Erich > > > > > > > |
