Just spouting this off the top of my head (or pulling it out of my ...;) but there is always an implementing class for the service, and somewhere in the handler chain that class is resolved to an instance, which may be new for each call, live across a session, or be a persistent instance of the service. Regardless, what about putting a getter/setter for message context in the service impl class and then shouldn't it be possible to create a handler that is invoked after the servicecall-to-instance resolution (is the the 'dispatch' phase? Anyone know for sure?) that injects the message context into the service impl for you?
Micheal, this is probably close to what you annotation does? If so I actually be interested the details of how it is accomplished. Thanks, Thatch -----Original Message----- From: Michel Drescher [mailto:[EMAIL PROTECTED] Sent: Friday, October 20, 2006 5:55 AM To: [email protected] Subject: Re: [xfire-user] MessageContext injection and binding generation Hi Yves, I thought about this as well, but this would break compatibility with JAX-WS, I believe: Adding the MessageContext to the method signature would force the MessageCOntext show up in the WSDL, and hence would require the client to provide a MessageContext as part of the operation invocation, and that is not what we want, right? Cheers, Michel Yves Langisch wrote: > This seems to be a general problem. > > What about the idea to add an additional flag to the generator class > whether the generated interfaces/classes should contain the > MessageContext in their method signatures or not? > > On Fri, 2006-10-20 at 10:14 +0100, Michel Drescher wrote: >> Hi Yves, >> >> Yves Langisch wrote: >>> Hi, >>> >>> We need to access the MessageContext in our service. Thus I added >>> the MessageContext to the service method signaure. Doing this I also >>> have to change the appropriate port interface. This works fine but >>> regenerating the classes with overwrite=false overwrites the port >>> interface and breaks the code since the impl class is not overwrited >>> (as expected). >>> >>> How can we handle this problem? >> I have/had the same problem. >> >> Since I use annotated interfaces, I created an Annotation that >> indicates that the MessageContext shall be injected into the >> implementation prior to the actual operation invocation. >> >> The solution works fine for me, but it is not in a proper state to >> publish it yet, as it is part of an undertake to refactor >> WS-Addressing support. >> >> But if you are nonetheless interested, I can dump some code on you >> (that relies on XFire 1.2.0) >> >> Cheers, >> Michel >> > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > -- Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com Fujitsu Laboratories of Europe +44 20 8606 4834 --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
