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 -~----------~----~----~----~------~----~------~--~---
