You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by "Neuberger, Nicholas (EHQ)" <NP...@express-scripts.com> on 2009/06/17 22:31:46 UTC
[TCPMON] request / response
Is there a specific location in the codebase for TcpMon where I can
intercept the request and responses in debug mode? So far, I've found
the class JTextAreaWriter.java I don't believe this is the right
class for a breakpoint, but that's where I'm started. I'm working with
what is in SVN / Trunk.
The feature what I'm tasked with doing is building out a recorder /
playback feature that could be possibly be integrated with TcpMon. I
want to store all of the request / responses into a persistence layer
for later playback during future project work. The intention is to
have a persistence store of various test scenarios.
If you need further implementation details let me know.
Thanks,
Nick
Re: [TCPMON] request / response
Posted by Saliya Ekanayake <es...@gmail.com>.
+1 this is a really nice feature.
Thanks,
Saliya
On Sat, Jun 20, 2009 at 5:16 PM, Andreas Veithen
<an...@gmail.com>wrote:
> I agree. The feature is interesting in itself, and will also allow us
> to improve the architecture of TCPMon.
>
> Andreas
>
> On Fri, Jun 19, 2009 at 04:32, Sanjiva Weerawarana<sa...@opensource.lk>
> wrote:
> > 2009/6/18 Neuberger, Nicholas (EHQ) <NP...@express-scripts.com>
> >
> >> Thanks a ton for the complete explanation of the core API. This will
> help
> >> a great deal for me to get started. I'll let you know my progress in
> the
> >> next day or two.
> >>
> >> I may ask your input on if you see this possible record/playback feature
> as
> >> a nice feature to TCPMon. If you find it valuable to contribute to the
> >> community let me know.
> >
> >
> > Its a great feature - I'd love to see it contributed!
> >
> > Sanjiva.
> > --
> > Sanjiva Weerawarana, Ph.D.
> > Founder, Director & Chief Scientist; Lanka Software Foundation;
> > http://www.opensource.lk/
> > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > Member; Apache Software Foundation; http://www.apache.org/
> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >
> > Blog: http://sanjiva.weerawarana.org/
> >
>
--
Saliya Ekanayake
http://www.esaliya.blogspot.com
http://www.esaliya.wordpress.com
Re: [TCPMON] request / response
Posted by Andreas Veithen <an...@gmail.com>.
Nick,
Please see my questions/comments inline.
Thanks,
Andreas
On Sat, Jul 11, 2009 at 06:49, Neuberger, Nicholas
(EHQ)<NP...@express-scripts.com> wrote:
> I'll give everyone a quick status of our progress on extending TcpMon with a record / playback functionality.
>
> Here's what we have now, but there are a few flaws.
>
> New Feature:
> *Added record / playback feature that is SOAP centric (this was our primary need).
What kind of SOAP processing framework does it use?
> **Added record / playback icon on the screen to turn on feature.
Did you integrate that into the Swing UI or the Eclipse plugin?
> *When R/P feature is on the following occurs:
>
> The incoming request is analyzed and parsed. All SOAP header information and XML soap request is parsed into a pojo/domain object. The object is then checked to determine if it is stored in the database. We are currently using hashCode for object identity, which appears to be a short term solution.
>
The parsing to POJO and the use of hashCode sounds like it's very
specific to your use case, or do I miss something?
> We compare the identity on the XML soap message only, and store other parts as additional fields like the following:
> --If it isn't then a request to the backend remote host is forwarded and the response is returned back to TcpMon and stored in the database. Final the response is returned back to the original request on the listening port.
>
> --If it is in the database, then the response from the db is returned back to the original request on the listening port.
>
>
> Currently we are using Spring / Hibernate for the persistence layer and MySQL for the local database. Now current implementation with these api's probably won't mesh well with a patch to an Apache project and GPL / Apache licensing. Also, we are going looking at building into the application an In-Memory database possibly (h2, hsqldb, or derby).
>
We already depend on Spring in other Apache projects. Not sure about
Hibernate though. For the database, Derby should be fine.
> The current implementation we have is SOAP centric but could possibly be enhanced for other things as well. And there are issues with using hashCode on the soap envelope. If any request comes in with any different value, then the remote server is called, which in some development cases, you wouldn't want that. In one scenario, a developer would want to always return the same response no matter what. Basically, an override table that if a request with a soap action of: findMyWidgets then always return a default down response.
>
> Thoughts? I'm open to any suggestions, criticism, ideas.
>
Some other questions that come to my mind:
- Is the feature completely optional, i.e. can TCPMon still be used as
before (in particular without the need to configure the database
connection) if the user doesn't need the R/P feature?
- What is the amount of change to the existing code base?
> Nick
>
> -----Original Message-----
> From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
> Sent: Saturday, June 20, 2009 6:47 AM
> To: commons-dev@ws.apache.org
> Subject: Re: [TCPMON] request / response
>
> I agree. The feature is interesting in itself, and will also allow us
> to improve the architecture of TCPMon.
>
> Andreas
>
> On Fri, Jun 19, 2009 at 04:32, Sanjiva Weerawarana<sa...@opensource.lk> wrote:
>> 2009/6/18 Neuberger, Nicholas (EHQ) <NP...@express-scripts.com>
>>
>>> Thanks a ton for the complete explanation of the core API. This will help
>>> a great deal for me to get started. I'll let you know my progress in the
>>> next day or two.
>>>
>>> I may ask your input on if you see this possible record/playback feature as
>>> a nice feature to TCPMon. If you find it valuable to contribute to the
>>> community let me know.
>>
>>
>> Its a great feature - I'd love to see it contributed!
>>
>> Sanjiva.
>> --
>> Sanjiva Weerawarana, Ph.D.
>> Founder, Director & Chief Scientist; Lanka Software Foundation;
>> http://www.opensource.lk/
>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>> Member; Apache Software Foundation; http://www.apache.org/
>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>
>> Blog: http://sanjiva.weerawarana.org/
>>
>
>
>
RE: [TCPMON] request / response
Posted by "Neuberger, Nicholas (EHQ)" <NP...@express-scripts.com>.
I'll give everyone a quick status of our progress on extending TcpMon with a record / playback functionality.
Here's what we have now, but there are a few flaws.
New Feature:
*Added record / playback feature that is SOAP centric (this was our primary need).
**Added record / playback icon on the screen to turn on feature.
*When R/P feature is on the following occurs:
The incoming request is analyzed and parsed. All SOAP header information and XML soap request is parsed into a pojo/domain object. The object is then checked to determine if it is stored in the database. We are currently using hashCode for object identity, which appears to be a short term solution.
We compare the identity on the XML soap message only, and store other parts as additional fields like the following:
--If it isn't then a request to the backend remote host is forwarded and the response is returned back to TcpMon and stored in the database. Final the response is returned back to the original request on the listening port.
--If it is in the database, then the response from the db is returned back to the original request on the listening port.
Currently we are using Spring / Hibernate for the persistence layer and MySQL for the local database. Now current implementation with these api's probably won't mesh well with a patch to an Apache project and GPL / Apache licensing. Also, we are going looking at building into the application an In-Memory database possibly (h2, hsqldb, or derby).
The current implementation we have is SOAP centric but could possibly be enhanced for other things as well. And there are issues with using hashCode on the soap envelope. If any request comes in with any different value, then the remote server is called, which in some development cases, you wouldn't want that. In one scenario, a developer would want to always return the same response no matter what. Basically, an override table that if a request with a soap action of: findMyWidgets then always return a default down response.
Thoughts? I'm open to any suggestions, criticism, ideas.
Nick
-----Original Message-----
From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Sent: Saturday, June 20, 2009 6:47 AM
To: commons-dev@ws.apache.org
Subject: Re: [TCPMON] request / response
I agree. The feature is interesting in itself, and will also allow us
to improve the architecture of TCPMon.
Andreas
On Fri, Jun 19, 2009 at 04:32, Sanjiva Weerawarana<sa...@opensource.lk> wrote:
> 2009/6/18 Neuberger, Nicholas (EHQ) <NP...@express-scripts.com>
>
>> Thanks a ton for the complete explanation of the core API. This will help
>> a great deal for me to get started. I'll let you know my progress in the
>> next day or two.
>>
>> I may ask your input on if you see this possible record/playback feature as
>> a nice feature to TCPMon. If you find it valuable to contribute to the
>> community let me know.
>
>
> Its a great feature - I'd love to see it contributed!
>
> Sanjiva.
> --
> Sanjiva Weerawarana, Ph.D.
> Founder, Director & Chief Scientist; Lanka Software Foundation;
> http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> Blog: http://sanjiva.weerawarana.org/
>
Re: [TCPMON] request / response
Posted by Andreas Veithen <an...@gmail.com>.
I agree. The feature is interesting in itself, and will also allow us
to improve the architecture of TCPMon.
Andreas
On Fri, Jun 19, 2009 at 04:32, Sanjiva Weerawarana<sa...@opensource.lk> wrote:
> 2009/6/18 Neuberger, Nicholas (EHQ) <NP...@express-scripts.com>
>
>> Thanks a ton for the complete explanation of the core API. This will help
>> a great deal for me to get started. I'll let you know my progress in the
>> next day or two.
>>
>> I may ask your input on if you see this possible record/playback feature as
>> a nice feature to TCPMon. If you find it valuable to contribute to the
>> community let me know.
>
>
> Its a great feature - I'd love to see it contributed!
>
> Sanjiva.
> --
> Sanjiva Weerawarana, Ph.D.
> Founder, Director & Chief Scientist; Lanka Software Foundation;
> http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> Blog: http://sanjiva.weerawarana.org/
>
Re: [TCPMON] request / response
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
2009/6/18 Neuberger, Nicholas (EHQ) <NP...@express-scripts.com>
> Thanks a ton for the complete explanation of the core API. This will help
> a great deal for me to get started. I'll let you know my progress in the
> next day or two.
>
> I may ask your input on if you see this possible record/playback feature as
> a nice feature to TCPMon. If you find it valuable to contribute to the
> community let me know.
Its a great feature - I'd love to see it contributed!
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software Foundation;
http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
RE: [TCPMON] request / response
Posted by "Neuberger, Nicholas (EHQ)" <NP...@express-scripts.com>.
Thanks a ton for the complete explanation of the core API. This will help a great deal for me to get started. I'll let you know my progress in the next day or two.
I may ask your input on if you see this possible record/playback feature as a nice feature to TCPMon. If you find it valuable to contribute to the community let me know.
BTW - I like some of the new cleanup items in the UI as well. We heavily use the XML Format option in the UI. The switch layout is nice as well.
-----Original Message-----
From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Sent: Wednesday, June 17, 2009 4:40 PM
To: commons-dev@ws.apache.org
Subject: Re: [TCPMON] request / response
Nick,
This is how TCPMon works (for the moment):
The core of TCPMon is the Interceptor class. It is responsible for
connection handling and for rewriting requests and responses (e.g. for
substituting the Host header when acting in man-in-the-middle mode).
You can pass an InterceptorListener implementation to the Interceptor.
For each request-response exchange, Interceptor will create a new
RequestResponseListener via
InterceptorListener#createRequestResponseListener. This instance will
receive a transcript of the request and response. All this part of the
code is completely independent of the UI.
The UI implements the InterceptorListener and RequestResponseListener
interfaces. In particular, (most of) the code implementing
RequestResponseListener is in AbstractRequestResponse. The interesting
stuff is happening in the getRequestOutputStream and
getResponseOutputStream methods. Each of them constructs a pipeline
with a set of filters, the last one of which decodes the byte stream
and sends it to a java.io.Writer. For the Swing UI this will be a
JTextAreaWriter.
This gives you several options:
- If you don't need the UI, just implement InterceptorListener and
RequestResponseListener and reuse the core of TCPMon, i.e.
Interceptor.
- If you need the UI, you can still to that, but since Interceptor can
have at most one InterceptorListener, you need to implement something
like a TeeInterceptorListener to dispatch to two listeners.
- Alternatively you can plug your code into getRequestOutputStream and
getResponseOutputStream in AbstractRequestResponse (maybe using a Tee
filter).
Note that I wrote "for the moment" above because the code is
undergoing some heavy refactoring which is not yet finished.
Regards,
Andreas
On Wed, Jun 17, 2009 at 22:31, Neuberger, Nicholas
(EHQ)<NP...@express-scripts.com> wrote:
>
> Is there a specific location in the codebase for TcpMon where I can
> intercept the request and responses in debug mode? So far, I've found
> the class JTextAreaWriter.java I don't believe this is the right
> class for a breakpoint, but that's where I'm started. I'm working with
> what is in SVN / Trunk.
>
>
> The feature what I'm tasked with doing is building out a recorder /
> playback feature that could be possibly be integrated with TcpMon. I
> want to store all of the request / responses into a persistence layer
> for later playback during future project work. The intention is to
> have a persistence store of various test scenarios.
>
> If you need further implementation details let me know.
>
> Thanks,
>
> Nick
>
>
Re: [TCPMON] request / response
Posted by Andreas Veithen <an...@gmail.com>.
Nick,
This is how TCPMon works (for the moment):
The core of TCPMon is the Interceptor class. It is responsible for
connection handling and for rewriting requests and responses (e.g. for
substituting the Host header when acting in man-in-the-middle mode).
You can pass an InterceptorListener implementation to the Interceptor.
For each request-response exchange, Interceptor will create a new
RequestResponseListener via
InterceptorListener#createRequestResponseListener. This instance will
receive a transcript of the request and response. All this part of the
code is completely independent of the UI.
The UI implements the InterceptorListener and RequestResponseListener
interfaces. In particular, (most of) the code implementing
RequestResponseListener is in AbstractRequestResponse. The interesting
stuff is happening in the getRequestOutputStream and
getResponseOutputStream methods. Each of them constructs a pipeline
with a set of filters, the last one of which decodes the byte stream
and sends it to a java.io.Writer. For the Swing UI this will be a
JTextAreaWriter.
This gives you several options:
- If you don't need the UI, just implement InterceptorListener and
RequestResponseListener and reuse the core of TCPMon, i.e.
Interceptor.
- If you need the UI, you can still to that, but since Interceptor can
have at most one InterceptorListener, you need to implement something
like a TeeInterceptorListener to dispatch to two listeners.
- Alternatively you can plug your code into getRequestOutputStream and
getResponseOutputStream in AbstractRequestResponse (maybe using a Tee
filter).
Note that I wrote "for the moment" above because the code is
undergoing some heavy refactoring which is not yet finished.
Regards,
Andreas
On Wed, Jun 17, 2009 at 22:31, Neuberger, Nicholas
(EHQ)<NP...@express-scripts.com> wrote:
>
> Is there a specific location in the codebase for TcpMon where I can
> intercept the request and responses in debug mode? So far, I've found
> the class JTextAreaWriter.java I don't believe this is the right
> class for a breakpoint, but that's where I'm started. I'm working with
> what is in SVN / Trunk.
>
>
> The feature what I'm tasked with doing is building out a recorder /
> playback feature that could be possibly be integrated with TcpMon. I
> want to store all of the request / responses into a persistence layer
> for later playback during future project work. The intention is to
> have a persistence store of various test scenarios.
>
> If you need further implementation details let me know.
>
> Thanks,
>
> Nick
>
>