Ok, _almost_ there :)
I updated castle to the current trunk and tried to apply the patch.
Did not "work". I tried to do it with turtoise svn, but it kept giving me
notification that the file to patch was not a working copy. (I think he
tries to get the file from svn if it is not there, can't and so fails)
drat!

Seems I will have to wait for it to appear at the trunk, which does not seem
overly far away, anyways.

I want to thank you for the work and energy you are putting into this and
for helping me out!!

--jan

2009/6/17 Henrik Feldt <[email protected]>

>
> Well, it was _almost_ applied, but was missing two of the test-case .cs
> files in the patch.
>
> I'll try and make the time to get those into the patch, but otherwise it
> seems that the patch was OKed. Right now, I'm moving between two different
> countries.
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Jason Townsend
> Sent: den 17 juni 2009 18:02
> To: [email protected]
> Subject: Re: Troubles with Automatic Transaction Facility (or something
> completely different)
>
> W
> -----Original Message-----
> From: Jan  Limpens <[email protected]>
>
> Date: Wed, 17 Jun 2009 08:24:24
> To: Castle Project Users<[email protected]>
> Subject: Re: Troubles with Automatic Transaction Facility (or something
> completely different)
>
>
>
> hi hendrik,
>
> any news of the trunk-state of the transaction patch?
>
> --jan
>
> On Jun 12, 2:46 pm, Jan  Limpens <[email protected]> wrote:
> > sorry, never meant to upset you! as project lead you are kind of
> > obliged to do that, of course, broad places of castle need resharper
> > code cleanup!
> > I just wanted to say, if I had to review the patch, in the position of
> > the lead receiving it from a 3rd party, I'd have a hard time to tell
> > what is actually changing :) and thus probably err on the side of
> > safety (an tell the dev to provide a cleaner patch before applying
> > it).
> >
> > apology accepted?
> >
> > so as the lead, I can ask you - will the patch enter the trunk, or
> > will it be necessary to maintain the patched classes in my local copy?
> >
> > --jan
> >
> > On Jun 12, 2:24 pm, "Henrik Feldt" <[email protected]> wrote:
> >
> > > Have you tried applying it and then looking at the code directly?
> >
> > > I don't force anyone to accept the patch, I did it because I needed it.
> And
> > > I'm the project leader for that project.................. It followed
> the
> > > guidelines and I think the methods are re-ordered to match the
> interface...
> > > Anyway, you do as you wish, the patch works and I have tested it.
> >
> > > -----Original Message-----
> > > From: [email protected]
> >
> > > [mailto:[email protected]] On Behalf Of Jan
> Limpens
> > > Sent: den 12 juni 2009 16:42
> > > To: Castle Project Users
> > > Subject: Re: Troubles with Automatic Transaction Facility (or something
> > > completely different)
> >
> > > On Jun 11, 11:16 pm, "Henrik Feldt" <[email protected]> wrote:
> > > > No, on the development list. Castle-project-devel
> > > Cannot find this anywhere, very strange.
> >
> > > It's very difficult to understand your patch because resharper made
> quite a
> > > mess with it. I seems it reordered every member of every class, so it
> is
> > > impossible to see what has changed. I would be surprised, if the path
> was
> > > accepted that way...
> >
> > > Right now I am a bit inclined to have nhibernate leak towards my
> controllers
> > > and leave the repository pattern to gain access to sessions and
> > > transactions...
> > > quite a bit of work, but could be done incrementally.
> >
> > > > -----Original Message-----
> > > > From: [email protected]
> >
> > > > [mailto:[email protected]] On Behalf Of Jan
> > > > Limpens
> > > > Sent: den 12 juni 2009 00:11
> > > > To: Castle Project Users
> > > > Subject: Re: Troubles with Automatic Transaction Facility (or
> > > > something completely different)
> >
> > > > On 11 Jun., 01:21, "Henrik Feldt" <[email protected]> wrote:
> > > > > Not quite. If you apply the patch I sent to the mailing list for
> the
> > > > > transactions a few days/weeks ago, you can decorate your method
> with
> > > > > [InjectTransaction] and have a parameter: "ITransaction tx" which
> > > > > then will have a method: "SetRollbackOnly()" which you can use to
> > > > > roll the transaction back.
> >
> > > > Interesting! Are you sure it was_this_ list? I could not find such a
> > > > post (I searched the group for 'InjectTransaction'...)
> >
> > > > > (Also only getting the innermost exception instead of the full
> > > > > stack-trace can probably cause you some trouble in the future when
> > > > > you don't know what code-path the thing went down.)
> >
> > > > In 99% of the cases this is where I get the relevant info from (and
> > > > the stack usually shows where it came from). But you are right, this
> > > > can go the wrong way...
> >
> > > > > In your case though, you have_a lot_ of things going on in your
> > > > > controller and you should definitely move it to a few domain and
> > > > > application services to maintain separation of concerns. That way
> > > > > you can also expose them as web services should you need to.
> >
> > > > Yip, this is the one super big method I am having in this site. But
> > > > actually it is already consuming a few services to construct an Order
> > > > object. This is a complicated process, but I doubt it would be less
> > > > complicated, if I put it into several methods without reuse. To me,
> > > > this would be a smell just as well...
> >
> > > > > May I ask how come you're returning view datas from your
> controller?
> > > > > Which view engine is that?
> >
> > > > I created a custom return binder, that puts the returned object into
> > > > PropertyBag["viewData"]. Just a few lines of code, but I hardly
> > > > address PropertyBag + strings that way. On view side I just go $
> > > > {viewData.SomeProperty}. The action needs the attribute
> > > > [return:PropertyBagReturnBinder]
> >
> > > > using System;
> > > > using Castle.MonoRail.Framework;
> >
> > > >         namespace ProjectBase.Utils
> > > >         {
> > > >                 [AttributeUsage(AttributeTargets.ReturnValue,
> > > > AllowMultiple = false, Inherited = false)]
> > > >                 public class PropertyBagReturnBinderAttribute :
> > > > Attribute, IReturnBinder
> > > >                 {
> > > >                         public void Bind(IEngineContext context,
> > > > IController controller, IControllerContext controllerContext, Type
> > > > returnType, object
> > > > returnValue)
> > > >                         {
> > > >
> > > > context.CurrentControllerContext.PropertyBag
> > > > [Name] = returnValue;
> > > >                         }
> >
> > > >                         private string name = "viewData";
> > > >                         public string Name
> > > >                         {
> > > >                                 get { return name; }
> > > >                                 set { name = value; }
> > > >                         }
> > > >                 }
> > > >         }
> >
> > > > Thanks!
> >
> > > > Jan
> >
> > > > > Cheers,
> > > > > Henrik
> >
> > > > > -----Original Message-----
> > > > > From: [email protected]
> >
> > > > > [mailto:[email protected]] On Behalf Of Jan
> > > > > Limpens
> > > > > Sent: den 10 juni 2009 22:43
> > > > > To: Castle Project Users
> > > > > Subject: Re: Troubles with Automatic Transaction Facility (or
> > > > > something completely different)
> >
> > > > > > Catching all exceptions will make the transaction try to commit.
> >
> > > > > So the only way to stop a transaction from committing would be to
> > > > > actively throw an exception and present it to the user as a rescue?
> > > > > I thought, the transaction would have been rolled back, before the
> > > > > exception was thrown to me.
> > > > > I am quite in a bit of trouble, if this is as you say...
> >
> > > > > > Could you send a small .sln with a repro?
> > > > > I will try...
> >
> > > > > > You're kind of eating the exceptions in a lot of places... Have
> > > > > > you tried letting the exception bubble out of the action instead,
> > > > > > using a [HandleError] page?
> >
> > > > > Actually I am catching my exceptions at the last possible instance,
> > > > > at the controller, where I am actually in the position to do
> > > > > something about it, if at least informing my users or redirecting
> or
> > > > > trying some different approach.
> >
> > > > > Most of the transaction intensive actions (form post actions) use
> > > > > JSONReturnBinder. I use a defined Json format to inform my users of
> > > > > possible errors. Dunno if I can use a [HandleError] page (==
> > > > > rescue??)
> > > > here.
> >
> > > > > In this special case everything goes fine database wise. The
> > > > > transaction_should_ commit, but it does not due to a failure in a
> > > > > totally different service.
> >
> > > > > Thanks!
> >
> > > > > Jan
> >
> > > >  file_tx_delta.rar
> > > > 29KViewDownload
> >
> >
>
>
>
>
>
> >
>


-- 
Jan

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Castle Project Users" 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-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to