I will apply your patch and run it on Windows 7 RC1. For future patches I would love that you don't use R# reformat as it adds a lot of noise.
-- Roelof On Tue, Jun 16, 2009 at 4:39 AM, Henrik Feldt <[email protected]> wrote: > > Well, the thing is that the majority of the changes aren't to already > existing code; it was barely changed (besides re-ordering through > re-sharper). 1000+ lines is the FileTransaction doing p/invoke into > kernel32.dll and methods when for example deleting recursively with TxF. > Changes to the core files, TransactionInterceptor is adding new meta-data > and also when inspecting, a new list with methodinfos for those methods > wanting the tx injected. > > It seems to be working OK and I got tests for it and they pass. I haven't > been able to find any bugs now for over a month, so I'm fairly confident it > works. Now, I don't plan on releasing just from that patch, but I kind of > need it as a baseline so I can add some other unit tests and have someone > running Mono and XP test it: the patch is tested on Vista but not on any > other Windows, so this is what I need help with; if people could apply the > patch and just try it, it would be nice (since I have changed a lot of > castle's code locally). > > So, I feel you can apply the patch and run the tests. > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of hammett > Sent: den 16 juni 2009 02:30 > To: [email protected] > Subject: Re: Castle Transactions > > > I checked the list and seems very cool. It will, though, de-stabilize what > we have, right? You may want to consider release what we have first, then > make such big changes. If you're confident the changes are stable, then let > us know too. > > > On Mon, Jun 15, 2009 at 1:37 PM, Henrik Feldt<[email protected]> wrote: > > > > Can I get a vote on whether the _functionality_ described below is to > > be added, from the rest of the people on this list, please? [+1, > > -1].Choice(); > > > > Then, I would appreciate something on the _actual_ implemented > > functionality as well. [+1, -1].Choice(); > > > > Either we do it or we don't do it. Very simple. Either way we should > > release v.1.x or v.2.0 of the service and stop delaying. I thought I > > was going to do PM on this project so we can start releasing stuff? > > > > Cheers > > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Henrik > > Feldt > > Sent: den 9 juni 2009 07:15 > > To: [email protected] > > Subject: RE: Castle Transactions > > > > > > Alright, thanks for answering, it helps planning. > > > > I don't have time right now to do a long write-up I'm afraid, so it > > would be better to go by unit tests, in terms of what it does, > > however, here are the major features of the changes: > > > > * Introducing IMapPath to bridge gap between desktop and web > > development with the same tools, mostly used when referring to the > > same folder as is the "current folder": "~/plugins" for example. > > * Introducing IFileAdapter and IDictionaryAdapter to wrap either Win32 > > API calls xor static File class calls in System.IO, or on linux > > possible calls to whatever DTC or file transaction APIs are available. > > Injected with dependency injection. > > * Introducing FileTransaction, plus its resource adapter with many > > lines of code, because p/invoke is lengthier to write code for. > > Contains most logic for many of the methods of the static class File, but > implemented with FtX. > > - FtX is used by Windows Update: " There are three core > > features in Windows Vista and Windows Server "Longhorn" that now make > > use of Transactional NTFS: Windows Update, System Restore, and Task > > Scheduler. All of these use TxF to write files to the file system > > within the scope of a transaction in order to handle rollback/commit > > in case of any exceptions, such as a system reboot due to a loss of > power." > > http://msdn.microsoft.com/en-us/magazine/cc163388.aspx as you probably > > already know. > > - I personally haven't been able to find a wrapper for C# for > > this, so I believe it's something good to add to the project. > > - I have tested this class extensively on my own projects so > > I'm pretty confident it works. If it doesn't, I'd like that input and > > is possible a repro. > > - The class inherits things IFileTransaction, but doesn't > > implement everything; relies on explicit interface implementations in > > order to specify similar operations of files and directories which are > > both file system objects (i-nodes) > > - By integrating with PathUtil which I built, some bugs with > > finding the root of a path in .net are corrected, by the use of regular > expressions. > > I think I put the test-case for it in the patch, but this as well has > > been tested a lot. > > - Supports UNC naming of paths, but this hasn't been > > extensively quality assured, so there may be cases where it's relying > > on some part of .Net's IO namespace which doesn't support it. > > * Introducing SafeTxHandle which by its inheritance chain extends > > CriticalFinalizerObject, and hence is a good way of improving > > reliability in the code. Since it's a safe handle, the finalizer is > > guaranteed to run and hence won't leak resources. Also, things > > inheriting this object will be weakly ordered to go before objects not > > inheriting it when GCed. See this article for more info: > > http://msdn.microsoft.com/en-us/magazine/dd419661.aspx > > * The Transaction Integration infrastructure (interceptor) has been > > extended to allow you to inject transactions into the method using it > > with the InjectTransactionAttribute class. > > > > So this is it. I've also personally integrated this with the > > NHibernateIntegration project so that persisted configurations are > > transacted; obviously very easy; just create a delegating class and > > slap [Transaction] on top of them, and redirect all File. and > > Directory. calls to use IFileAdapter and IDirectoryAdapter, and you're > done. > > > > I can't fathom a "small code spike" for this. It's either or; > > implement a part of it with transactions and ALL of your file accesses > > need to use the same transactions of by definition of isolation in > > ACID, you won't be able to see the changes to the file system. (!) > > > > So this is it, not much more, I'm afraid. I hope you have gained an > > insight into the patch and can make a decision from this, or otherwise > > will let me know! > > > > Regards, > > Henrik > > > > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of hammett > > Sent: den 9 juni 2009 00:53 > > To: [email protected] > > Subject: Re: Castle Transactions > > > > > > I took a peak at the patch. Seems very promising! > > But I agree with Roelof, big changes should happen in small steps. > > > > Thanks > > > > On Mon, Jun 8, 2009 at 11:37 AM, Roelof Blom<[email protected]> > wrote: > >> Henrik, > >> > >> I've seen your patch and was quite overwhelmed by the sheer amount of > >> changes, pPerhaps you should start by explaining what your patch is > >> supposed to do; you sent a 4000+ line patch file out of the blue > >> stating 'AutomaticTransactionManagement needs to be updated with a > >> bit of code [...]'. Start a discussion to gain feedback, supply a > >> small code spike, try to gather interest for your feature on the list > >> and/or > > UserVoice. > >> > >> A sample spec like this > >> http://using.castleproject.org/display/AR/NHEventListenerSpecs would > >> also be a good thing for such a complex feature you are proposing. > >> > >> -- Roelof. > >> > >> > >> > >> On Mon, Jun 8, 2009 at 7:46 PM, Henrik Feldt <[email protected]> wrote: > >>> > >>> However, considering I can’t commit nor get anyone answering my > >>> e-mails about this (the patch I sent + testing it out), how am I > >>> supposed to get somewhere with this? If I’m supposedly in charge of > >>> the transaction project, surely I could have access to that specific > >>> part of the trunk or otherwise have someone actually commit my changes? > >>> > >>> > >>> > >>> From: [email protected] > >>> [mailto:[email protected]] On Behalf Of Henrik > >>> Feldt > >>> Sent: den 31 maj 2009 15:22 > >>> To: [email protected] > >>> Subject: RE: Castle Transactions > >>> > >>> > >>> > >>> Man, you’re great to have when I hadn’t slept for way too long! J > >>> > >>> > >>> > >>> From: [email protected] > >>> [mailto:[email protected]] On Behalf Of Roelof > >>> Blom > >>> Sent: den 31 maj 2009 07:52 > >>> To: [email protected] > >>> Subject: Re: Castle Transactions > >>> > >>> > >>> > >>> Check Environment.OSVersion.Platform? > >>> > >>> On Sun, May 31, 2009 at 2:00 AM, Henrik Feldt <[email protected]> wrote: > >>> > >>> If there is something similar for Mono, that would be great, because > >>> we wouldn’t need platform-specific compiles… > >>> > >>> > >>> > >>> Regards, > >>> > >>> Henrik > >>> > >>> > >>> > >>> From: [email protected] > >>> [mailto:[email protected]] On Behalf Of Roelof > >>> Blom > >>> Sent: den 30 maj 2009 23:51 > >>> > >>> To: [email protected] > >>> Subject: Re: Castle Transactions > >>> > >>> > >>> > >>> You need to check at runtime, don't you? Use something like this > >>> > >>> if(Environment.OSVersion.Version.Major > 5) { /* vista and above */ > >>> } > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Sun, May 31, 2009 at 12:16 AM, Henrik Feldt <[email protected]> wrote: > >>> > >>> Actually, no, because it’s built on the vista kernel and hence > >>> supports TxF and TxR, but I’m not sure what to do about Win5 and > >>> lesser. Is there some sort of compile-constant for it? This is the > >>> way it currently looks, and I think I need something pre-vista and > >>> not > > just MONO: > >>> > >>> > >>> > >>> Example: > >>> > >>> /// <summary> > >>> > >>> /// Deletes a folder recursively. > >>> > >>> /// </summary> > >>> > >>> /// <param name="path"></param> > >>> > >>> public void Delete(string path) > >>> > >>> { > >>> > >>> AssertAllowed(path); > >>> > >>> #if !MONO > >>> > >>> IFileTransaction tx; > >>> > >>> if (HasTransaction(out tx)) > >>> > >>> { > >>> > >>> ((IDirectoryAdapter)tx).Delete(path); > >>> > >>> return; > >>> > >>> } > >>> > >>> #endif > >>> > >>> Directory.Delete(path); > >>> > >>> } > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> From: [email protected] > >>> [mailto:[email protected]] On Behalf Of Roelof > >>> Blom > >>> Sent: den 30 maj 2009 20:15 > >>> > >>> To: [email protected] > >>> Subject: Re: Castle Transactions > >>> > >>> > >>> > >>> Non-Vista would also be Windows 7 RC? > >>> > >>> On Sat, May 30, 2009 at 9:03 PM, Henrik Feldt <[email protected]> wrote: > >>> > >>> Cool, np. I’ve changed it. Quite ready to commit now. I guess it’s > >>> patching that’s it for me, right… > >>> > >>> > >>> > >>> I need someone to test on non-vista systems and mono to make sure > >>> the new code paths don’t become activated. Volunteers? > >>> > >>> > >>> > >>> Cheers, > >>> > >>> Henke > >>> > >>> > >>> > >>> From: [email protected] > >>> [mailto:[email protected]] On Behalf Of Jonathon > >>> Rossi > >>> Sent: den 30 maj 2009 16:18 > >>> To: [email protected] > >>> Subject: Re: Castle Transactions > >>> > >>> > >>> > >>> Shouldn't it be using Castle's ILogger in Castle.Core, which > >>> indirectly can depend on log4net. > >>> > >>> On Sat, May 30, 2009 at 8:34 PM, Henrik Feldt <[email protected]> wrote: > >>> > >>> Can we make it depend on log4net? > >>> > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Jono > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >> > > >> > > > > > > > > -- > > Cheers, > > hammett > > http://hammett.castleproject.org/ > > > > > > > > > > > > > > > > > > > -- > Cheers, > hammett > http://hammett.castleproject.org/ > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
