Hi Chamikara, Ok. I understand. As a last question. I was looking through the InOrderInvoker code and saw a loop with a sleep time of 1 second for each loop. Won't this break performance? Also, are all sequences of messages processed by this one thread?
Thanks, Lennard. ----- Original Message ----- From: Chamikara Jayalath <[EMAIL PROTECTED]> Date: Thursday, August 3, 2006 2:16 pm Subject: Re: [Axis2] Sandesha2 and Rampart module > Hi Lennard, > > Please see my comments below, > > > On 8/3/06, L YSSELSTEIN <[EMAIL PROTECTED]> wrote: > > > > Hi Chamikara, > > > > Basically, what we are trying to do is this. When the first > invocation> passes the security handler, the handler checks the > user credentials. > > If the username/password is valid, the userprofile is retrieved > from Ldap > > and stored in a context for future reference. > > > > From the security handler we cannot store it in the message > context. The > > callback interface does not give a handle to the message context. > > > > This leaves us with the following questions. > > How can we store the userprofile in the current messagecontext? > > > > I guess ruchith will answer this. > > > Also, why does sandesha skip the security phase when resuming a > message in > > the InOrderInvoker? > > > > Sandesha does not skip any phases. It simply does not repeatedly > send it > through the same Phase. > > If you consider the Application Message when Sandesha2 is not > engaged it > will go through following set of phases. > > Transport > Security > PreDispatch > Dispatch > RMPhase > OperationOutPhase > RMPhase > OperationInPhase > > > When RM is present it will go through the usual set of Phases but > sinceInOrder invocation is enabled message will be paused at the > RMPhase. So it > will go through following phases in the first go. > > Transport > Security > PreDispatch > Dispatch > RMPhase > > > Later Sandesha InOrderInvoker thread will resume the message. (this > guarantees that the messages are invoked in the order of RM Message > Numbers). So the message will go through the rest of the Phases. > > RMPhase > OperationInPhase > > > Thanks, > > > > Lennard. > > > > ----- Original Message ----- > > From: Chamikara Jayalath <[EMAIL PROTECTED]> > > Date: Thursday, August 3, 2006 11:31 am > > Subject: Re: [Axis2] Sandesha2 and Rampart module > > > > > Hi Lennard, > > > > > > I'm not fully getting it. What do u mean by a Security Context. > To my > > > knwoedge security handler saves all the information to the message > > > context. > > > The storage framework should not loose any information when > saving and > > > retrieving information. In the in-memory implementation Message > > > Context is > > > simply stored in a HashMap and properties and all other > information> > shouldbe there when the message is resumed. > > > > > > R u saying that some of these properties are lost when the > message is > > > resumed by the Sandesha2 InOrderInvoker ? > > > > > > Chamikara > > > > > > > > > On 8/3/06, L YSSELSTEIN <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi Chamikara, > > > > > > > > Ok, I understand. > > > > During debugging I can see the first invocation to be passed > > > through the > > > > security phase. > > > > The problem is that during the security phase the security > > > handler is > > > > adding user information to a acegi security context. > > > > This context only exists during each invocation. > > > > Because during the second invocation this security handler is > not> > called,> no user information is available. Because of this > the soap > > > call cannot be > > > > processed correctly. > > > > Can we add the user information to the storage framework of > > > sandesha2?> > > > > Thanks, > > > > > > > > Lennard. > > > > > > > > ----- Original Message ----- > > > > From: Chamikara Jayalath <[EMAIL PROTECTED]> > > > > Date: Thursday, August 3, 2006 5:30 am > > > > Subject: Re: [Axis2] Sandesha2 and Rampart module > > > > > > > > > Hi Lennard, > > > > > > > > > > There is no way a message could reach the RM Phase without > going> > > > trough the > > > > > global phases (this include Transport, Security, Dispatch > phases).> > > > If you > > > > > have enable In-Order invocation in Sandesha2 (which is the > > > > > default), it has > > > > > following behaviour. > > > > > > > > > > Every incoming application will be paused at the RMPhase. > So in > > > the> > firstinvocation the messages will go through the Global > > > Phases and the > > > > > Application Phases upto the RM Phase. Later Sandesha2 will > invoke> > > > application message in the order of Message Numbers. > So if you are > > > > > monitorning in the second invocation you will only see a > set of > > > > > Applicationlevel Phases. But this message must have gone > through> > > > the Security Phase in > > > > > its first invocation. Therefore this does not produce a > > > security hole. > > > > > > > > > > Chamikara > > > > > > > > > > > > > > > > > > > > On 8/2/06, Lennard IJsselstein <[EMAIL PROTECTED]> > > > wrote:> > > > > > > > > Hi Ruchith, > > > > > > > > > > > > I also expected the phases you mentioned. But when I > check the > > > > > > executionChain in the messagecontext while debugging I only > > > see the > > > > > > phases I mentioned before. For some reason sandesha2 > alters the > > > > > phases> of the messages during invocation. > > > > > > > > > > > > Before sandesha2 was added the execution chain was as you > > > described.> > > > > > > > > Thanks, > > > > > > > > > > > > Lennard. > > > > > > || > > > > > > Ruchith Fernando wrote: > > > > > > > > > > > > > Hi Lennard, > > > > > > > > > > > > > > On 8/2/06, Lennard IJsselstein > <[EMAIL PROTECTED]>> > > > wrote:> > > > > > > > >> Hi all, > > > > > > >> > > > > > > >> We are currently using both the Sandesha2 and the Rampart > > > module.> > > >> The problem we are facing now is when we send a > > > webservice> > call the > > > > > > >> following happens: > > > > > > >> - The CreateSequence soapmessage is send to the Axis2 > servlet> > > > and is > > > > > > >> correctly processed. > > > > > > >> As expected the following axis2 phases are hit: > > > > > > >> Transport, Security, RMPhase OperationInPhase > > > > > > >> - The soapmessage with the actual webservice call is > send to > > > > > the Axis2 > > > > > > >> servlet. > > > > > > >> The following phases are hit: > > > > > > >> soapmonitorPhase, RMPhase, OperationInPhase. > > > > > > >> - The TerminateSequence soapmessage is send to the Axis2 > > > > > servlet and is > > > > > > >> correctly processed. > > > > > > >> As expected the following axis2 phases are hit: > > > > > > >> Transport, Security, RMPhase, OperationInPhase > > > > > > >> > > > > > > >> Our question is: > > > > > > >> Why does the 'normal' soapmessage not run through the > > > > > Security> >> phase? > > > > > > > > > > > > > > > > > > > > > IMHO the request message should go through the following > > > phases : > > > > > > > Transport, Security, PreDispatch, Dispatch, > OperationInPhase> > > > > > > > > > > > > Transport and Dispatch phases are used to dispatch and > since> > > > you have > > > > > > > not mentioned any of these in the phases that the soap > message> > > > hit I > > > > > > > wonder how the request reached the OperationInPhase. > > > > > > > > > > > > > > Thanks, > > > > > > > Ruchith > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------- > ---- > > > ---- > > > > > --- > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: axis-user- > [EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > ---- > > > --- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > ------------------------------------------------------------------ > --- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
