Again as we were evaluating other approaches to use the functionality of CXF
interceptors directly in the  server side(Without CXF custom transport). 

So the goal was to get the processed message out of the CXF inbound
interceptors and the process the message(just like we do in
MySourcePayloadProvider) basically this interceptor has the business logic 
to do custom stuff and the modify the soapmessage and then set it back to a
place where the next interceptors in chain would pick the modified
message(by our business layer) 

And  so we could see that CXF stack maintains an arraylist the 1st element
is the key and the second element is the stream.and we saw that
MessageContentList.class was the key and StaxSource wrapped stream was the
2nd element. 
So we tried overwriting 
MessageContentsList list = (MessageContentsList) message 
                                  .getContent(List.class); 
                     if (list == null) { 
                           list = new MessageContentsList(); 
                           message.setContent(List.class, list); 
                     } 
                     Reader reader = new StringReader(responseData);  --
Here we are creating a reader with modified soap message which has been
processed by our business layer 
                     XMLInputFactory factory =
XMLInputFactory.newInstance(); // Or 
                                                                                
                                           
// newFactory() 
                     XMLStreamReader xmlReader; 

                     xmlReader = factory.createXMLStreamReader(reader); 

                     list.set(0, new StaxSource(xmlReader)); 
                    
message.getExchange().getOutMessage().setContent(List.class, list); 
                     message.getExchange().getOutMessage() 
                                  .setContent(OutputStream.class, new
CachedOutputStream()); 
The concern we are having is we are trying to use Internal API's , although
this is a core logic in CXF for message retrieval in interceptors ,we fear
that it could be changed. 
Please provide your comments on this. 

The reason I don’t want to go use CXF custom transport is that the invoke()
of PegaServiceProvider just has the argument as StackSource and there is no
way I can share the objects related to our business layer so that we can do
processing inside invoke(). 
// TODO Auto-generated method stub

> > try{ 
> > setUp(); 
> > PegaServiceProvider hello = new PegaServiceProvider(); 
> > String address = "http://localhost:9000/hello";; 
> > Endpoint.publish(address, hello); 
> > 
> > 
> > }catch(Exception e){ 
> > e.printStackTrace(); 
> > } 
> >
... [show rest of quote]

Let us know your opinion on this. 

Also we were wondering why we are using a arraylist based implementation
when we do MessageContentsList list = (MessageContentsList) message 
                                  .getContent(List.class); 

The first element is the key and the 2nd element its value and so on and so
for ,for other objects in arraylist. 
Is there any specific reason we did not use map for this purpose? 

 



--
View this message in context: 
http://cxf.547215.n5.nabble.com/Interceptors-on-Service-Side-tp5741102.html
Sent from the cxf-user mailing list archive at Nabble.com.

Reply via email to