DO NOT REPLY [Bug 46030] New: Extend TCP Sampler to Support Length-Prefixed Binary Data
https://issues.apache.org/bugzilla/show_bug.cgi?id=46030 Summary: Extend TCP Sampler to Support Length-Prefixed Binary Data Product: JMeter Version: 2.3.2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Main AssignedTo: jmeter-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Created an attachment (id=22749) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22749) Code to implement enhancement We have a requirement to test a TCP service where data is exchanged in length-prefixed binary format. To meet this need we have implemented the attached classes which we wish to submit for a future release of JMeter. A brief description of the classes follows: BinaryTCPClientImpl Concrete class which implements TCPClient Interface and converts hex-encoded strings to byte array in write(OutputStream, String) and from byte array to hex-encoded string in read(InputStream). write(OutputStream, InputStream) is unsupported. Contains utility method hexStringToByteArray(String s) which is a mirror of the JOrphanUtils.baToHexString(byte[]) method. TCPClientDecorator Abstract class implementing TCPClient Interface. This is to allow wrapping of TCPClientImpl/BinaryTCPClientImpl above with length prefixing methods. Contains two utility methods intToByteArray(int value, int len) and byteArrayToInt(byte[] b). Methods support 2 and 4 and byte lengths only and throw an IllegalArgumentException in other cases. LengthPrefixedBinaryTCPClientImpl Extends TCPClientDecorator and instantiates decorator with BinaryTCPClientImpl. The length to use in the prefix is taken from the properties file and defaults to 2. For write(OutputStream os, String s) the length is calculated and written to the output stream then the method delegates to the BinaryTCPClientImpl write() method. read(InputStream is) is overridden. write(OutputStream os, InputStream is) is not supported. Have created JUnit tests for the three utility methods but not for the read/write implementations themselves. These are in two test classes, BinaryTCPClientImplTest and TCPClientDecoratorTest. Have left the utility methods bundled with the client implementations to avoid modifying existing utility classes. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Graham Little is out of the office.
I will be out of the office starting 17/10/2008 and will not return until 20/10/2008. I will respond to your message when I return. ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify [EMAIL PROTECTED] This footnote also confirms that this email message has been checked for all known viruses. Sony Computer Entertainment Europe Limited Registered Office: 10 Great Marlborough Street, London W1F 7LP, United Kingdom Registered in England: 3277793 ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FW: TCP Sampler Extension to support length-prefixed binary data
Thanks, have created enhancement bug 46030 and attached source to it. In relation to the ICLA/CCLA, does this qualify the individual/company to be listed as a contributor to the project and should we send in both or can we just send in a CCLA? -Original Message- From: sebb [mailto:[EMAIL PROTECTED] Sent: 15 October 2008 11:50 To: JMeter Developers List Subject: Re: FW: TCP Sampler Extension to support length-prefixed binary data On 15/10/2008, Oghie Sheehy <[EMAIL PROTECTED]> wrote: > Hello again, > > Have implemented the following: > > BinaryTCPClientImpl > Concrete class which implements TCPClient Interface and converts hex-encoded > strings to byte array in > write(OutputStream, String) and from byte array to hex-encoded string in > read(InputStream). > write(OutputStream, InputStream) is unsupported. > Contains utility method hexStringToByteArray(String s) which is a mirror of > the JOrphanUtils.baToHexString(byte[]) method. > > TCPClientDecorator > Abstract class implementing TCPClient Interface. This is to allow wrapping > of TCPClientImpl/BinaryTCPClientImpl above with length prefixing methods. > Contains two utility methods intToByteArray(int value, int len) and > byteArrayToInt(byte[] b). Methods support 2 and 4 and byte lengths only and > throw an IllegalArgumentException in other cases. > > LengthPrefixedBinaryTCPClientImpl > Extends TCPClientDecorator and instantiates decorator with > BinaryTCPClientImpl. > The length to use in the prefix is taken from the properties file and > defaults to 2. > For write(OutputStream os, String s) the length is calculated and written to > the output stream then the method delegates to the BinaryTCPClientImpl > write() method. > read(InputStream is) is overridden. > write(OutputStream os, InputStream is) is not supported. > > Have created JUnit tests for the three utility methods but not for the > read/write implementations themselves. These are in two test classes, > BinaryTCPClientImplTest and TCPClientDecoratorTest. > > Have left the utility methods bundled with the client implementations to > avoid modifying existing utility classes. > > Have not changed the Sampler GUI as we might end up with some broken test > cases when this is changed in the repository. We will change the properites > file as needed for now. > > Hopefully this will be useful and we are happy for the code structure to be > modified if it does not turn out to be a good fit with changes to the > TCPClient interface discussed earlier. All sounds good. > What should we do next in terms of submitting this code for inclusion in a > future release? Create a Bugzilla enhancement issue, and attach the files/patches to that. Please make sure any new source files have the usual Apache Licence header. As the code contributions are quite substantial, it would be helpful if the contributor(s) could sign ICLAs. You may also want to provide a CCLA from the company. For details, please see: http://www.apache.org/licenses/#clas > Thanks, Thank you! > Oghie. > > > -Original Message- > From: Oghie Sheehy > Sent: 13 October 2008 08:53 > To: 'JMeter Developers List' > Cc: Mike Cronin > > Subject: RE: TCP Sampler Extension to support length-prefixed binary > data > > > > Yes, I can do the updates to the TCPSampler. > > > I think you can still test your code using the current JMeter, so long > > as you use the old TCPClient interface methods. Converting to the new > > interface could be done later when the TCP Sampler is updated. Should > > be fairly trivial - I'm happy to do that. > > Thanks, will use existing interface. > > -Original Message- > From: sebb [mailto:[EMAIL PROTECTED] > Sent: 10 October 2008 16:27 > To: JMeter Developers List > Cc: Mike Cronin > Subject: Re: TCP Sampler Extension to support length-prefixed binary > data > > > On 10/10/2008, Oghie Sheehy <[EMAIL PROTECTED]> wrote: > > > Yes, but the character set is largely irrelevant, as the hex > > > characters are the same in most (all?) sets. > > > > > > > I was assuming that the hex-encoded binary string would be converted > > > to binary in the client. This does not really need a variable encoding > > > as hex characters are the same in all main character sets, but for > > > portability the client could use a fixed set, e.g. 8859-1 or utf-8. > > > > > > Likewise for the binary->hex conversion. The client could convert > > > binary nibbles to character string and then to bytes, but since we > > > know the conversion for these they could be converted direct to bytes. > > > > > > The character set used to display the response would not matter in this > case. > > > > > > Thanks, needed to be sure we were talking about the same thing and > wondered whether hex representation was different according to character set. > > > > So guess I'm back to what we agreed a few days ago... > > > > Will create client(s) to sup
Re: FW: TCP Sampler Extension to support length-prefixed binary data
On 17/10/2008, Oghie Sheehy <[EMAIL PROTECTED]> wrote: > Thanks, have created enhancement bug 46030 and attached source to it. Thanks, I'll have a look later. > In relation to the ICLA/CCLA, does this qualify the individual/company to be > listed as a contributor to the project and should we send in both or can we > just send in a CCLA? > The ICLA/CCLA don't have any bearing on whether or not a contributor is listed. [The JMeter contributor list is on the Wiki, so people can add themselves.] The ASF requires the ICLA which is signed by the author of the code. The CCLA is optional, and depends on whether you think you need one. > > -Original Message- > From: sebb [mailto:[EMAIL PROTECTED] > > Sent: 15 October 2008 11:50 > To: JMeter Developers List > > Subject: Re: FW: TCP Sampler Extension to support length-prefixed binary > data > > > On 15/10/2008, Oghie Sheehy <[EMAIL PROTECTED]> wrote: > > Hello again, > > > > Have implemented the following: > > > > BinaryTCPClientImpl > > Concrete class which implements TCPClient Interface and converts > hex-encoded strings to byte array in > > write(OutputStream, String) and from byte array to hex-encoded string in > read(InputStream). > > write(OutputStream, InputStream) is unsupported. > > Contains utility method hexStringToByteArray(String s) which is a mirror > of the JOrphanUtils.baToHexString(byte[]) method. > > > > TCPClientDecorator > > Abstract class implementing TCPClient Interface. This is to allow > wrapping of TCPClientImpl/BinaryTCPClientImpl above with length prefixing > methods. > > Contains two utility methods intToByteArray(int value, int len) and > byteArrayToInt(byte[] b). Methods support 2 and 4 and byte lengths only and > throw an IllegalArgumentException in other cases. > > > > LengthPrefixedBinaryTCPClientImpl > > Extends TCPClientDecorator and instantiates decorator with > BinaryTCPClientImpl. > > The length to use in the prefix is taken from the properties file and > defaults to 2. > > For write(OutputStream os, String s) the length is calculated and written > to the output stream then the method delegates to the BinaryTCPClientImpl > write() method. > > read(InputStream is) is overridden. > > write(OutputStream os, InputStream is) is not supported. > > > > Have created JUnit tests for the three utility methods but not for the > read/write implementations themselves. These are in two test classes, > BinaryTCPClientImplTest and TCPClientDecoratorTest. > > > > Have left the utility methods bundled with the client implementations to > avoid modifying existing utility classes. > > > > Have not changed the Sampler GUI as we might end up with some broken test > cases when this is changed in the repository. We will change the properites > file as needed for now. > > > > Hopefully this will be useful and we are happy for the code structure to > be modified if it does not turn out to be a good fit with changes to the > TCPClient interface discussed earlier. > > All sounds good. > > > What should we do next in terms of submitting this code for inclusion in > a future release? > > Create a Bugzilla enhancement issue, and attach the files/patches to that. > Please make sure any new source files have the usual Apache Licence header. > > As the code contributions are quite substantial, it would be helpful > if the contributor(s) could sign ICLAs. You may also want to provide > a CCLA from the company. > > For details, please see: > > http://www.apache.org/licenses/#clas > > > Thanks, > > Thank you! > > > Oghie. > > > > > > -Original Message- > > From: Oghie Sheehy > > Sent: 13 October 2008 08:53 > > To: 'JMeter Developers List' > > Cc: Mike Cronin > > > > Subject: RE: TCP Sampler Extension to support length-prefixed binary > > data > > > > > > > Yes, I can do the updates to the TCPSampler. > > > > > I think you can still test your code using the current JMeter, so long > > > as you use the old TCPClient interface methods. Converting to the new > > > interface could be done later when the TCP Sampler is updated. Should > > > be fairly trivial - I'm happy to do that. > > > > Thanks, will use existing interface. > > > > -Original Message- > > From: sebb [mailto:[EMAIL PROTECTED] > > Sent: 10 October 2008 16:27 > > To: JMeter Developers List > > Cc: Mike Cronin > > Subject: Re: TCP Sampler Extension to support length-prefixed binary > > data > > > > > > On 10/10/2008, Oghie Sheehy <[EMAIL PROTECTED]> wrote: > > > > Yes, but the character set is largely irrelevant, as the hex > > > > characters are the same in most (all?) sets. > > > > > > > > > > I was assuming that the hex-encoded binary string would be converted > > > > to binary in the client. This does not really need a variable > encoding > > > > as hex characters are the same in all main character sets, but for > >
Re: maven-jmeter-plugin call to jmeter leaking threads
The JMeter Maven plugin is not a part of JMeter; as far as I can tell
it originates here:
http://wiki.apache.org/jakarta-jmeter/JMeterMavenPlugin
I'm not sure if it is maintained anywhere else.
I suggest adding the proposed fixes to the Wiki page - anyone can
create a login and edit these (that's how the plugin was added).
On 15/10/2008, Peter Andersen <[EMAIL PROTECTED]> wrote:
> Hi
>
> Using jmeter from maven-jmeter-plugin as sugested on:
>
> http://jlorenzen.blogspot.com/2008_03_01_archive.html
>
> The problem is that maven hang after the test has ended.
>
> Some debugging shows that the maven-jmeter-plugin call to jmeter course
> jmeter to leak threads,
> I have done the following change to the maven-jmeter-plugin that fixes the
> problem, using checkForEndOfTest method below.
>
> Hope someone can use this to improve the plugin.
>
> --
> Med venlig hilsen / Best Regards
> Peter Andersen
> [EMAIL PROTECTED]
> Lenio A/S
> +45 3061 0012
>
> Code changes to org.apache.jmeter.JMeterMojo.java:
>
> private void executeTest(File test) throws MojoExecutionException {
> /...cut out from mail
> try {
> // This mess is necessary because the only
> way to know when JMeter
> // is done is to wait for all of the threads
> that it spawned to exit.
> new
> JMeter().start(args.toArray(new String[]{}));
> BufferedReader in = new BufferedReader(new
> FileReader(jmeterLog));
> while (!checkForEndOfTest(in)) {
> try {
> Thread.sleep(1000);
> } catch (InterruptedException e) {
> break;
> }
> }
> in.close();
> } catch (ExitException e) {
> if (e.getCode() != 0) {
> throw new
> MojoExecutionException("Test failed", e);
> }
> } finally {
>
> System.setSecurityManager(oldManager);
>
> Thread.setDefaultUncaughtExceptionHandler(oldHandler);
> }
> } catch (IOException e) {
> throw new MojoExecutionException("Can't execute
> test", e);
> }
> }
>
> private boolean checkForEndOfTest(BufferedReader
> in) throws MojoExecutionException {
> boolean testEnded = false;
> try {
> String line;
> while ( (line = in.readLine()) != null) {
> if (line.indexOf("Test has ended") != -1) {
> testEnded = true;
> break;
> }
> }
> } catch (IOException e) {
> throw new MojoExecutionException("Can't read log
> file", e);
> }
> return testEnded;
> }
>
>
>
>
>
>
> -
> 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]
[Jakarta-jmeter Wiki] Update of "JMeterTesting/ASPNETViewState" by JMeterAdmin
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Jakarta-jmeter Wiki"
for change notification.
The following page has been changed by JMeterAdmin:
http://wiki.apache.org/jakarta-jmeter/JMeterTesting/ASPNETViewState
The comment on the change is:
Minor simplification
--
- Describe JMeterTesting/ASPNETViewState here.
-
-
Testing ASP.NET Web pages will require two hidden fields (_VIEWSTATE and
_EVENTVALIDATION) to be passed for subsequent requests to a web page once the
hidden fields have been set in the body. This can be achieved by creating two
post Processor elements of the type 'Regular Expression Extractor' and then
setting the details of the Regular Expressions as follows:
[[BR]][[BR]]
Response Field to check: Body [[BR]]
Reference Name: VIEWSTATE [[BR]]
- Regular Expression: id=\"_VIEWSTATE\" value=\"([\\w/-_].+)\" [[BR]]
+ Regular Expression: id="_VIEWSTATE" value="([\\w/-_].+)" [[BR]]
- Template: $0$ [[BR]]
+ Template: $1$ [[BR]]
Match No. : 1 [[BR]]
Default Value: NOT FOUND [[BR]]
[[BR]]
Response Field to check: Body [[BR]]
Reference Name: EVENTVALIDATION [[BR]]
- Regular Expression: id=\"_EVENTVALIDATION\" value=\"([\\w/-_].+)\" [[BR]]
+ Regular Expression: id="_EVENTVALIDATION" value="([\\w/-_].+)" [[BR]]
- Template: $0$ [[BR]]
+ Template: $1$ [[BR]]
Match No. : 1 [[BR]]
Default Value: NOT FOUND [[BR]]
[[BR]]
Then in order to ensure these extracted values are passed in subsequent HTTP
requests, for each request specify the following to be the Send Parameters for
the Request:
[[BR]]
Name: _VIEWSTATE [[BR]]
- Value: ${VIEWSTATE_g1} [[BR]]
+ Value: ${VIEWSTATE} [[BR]]
[[BR]]
Name: _EVENTVALIDATION [[BR]]
- Value: ${EVENTVALIDATION_g1} [[BR]]
+ Value: ${EVENTVALIDATION} [[BR]]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-jmeter Wiki] Update of "JMeterMavenPlugin" by PeterAndersen
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Jakarta-jmeter Wiki"
for change notification.
The following page has been changed by PeterAndersen:
http://wiki.apache.org/jakarta-jmeter/JMeterMavenPlugin
--
'''Executing the Plugin'''
* Run "mvn org.apache.jmeter:maven-jmeter-plugin:jmeter" to run the tests.
+ '''Change to the plugin - by Peter Andersen / not committed!'''
+
+ (If this can be used - please commit this into the codebase)
+
+ Using jmeter from maven-jmeter-plugin as suggested on:
+
+ http://jlorenzen.blogspot.com/2008_03_01_archive.html
+
+ The problem is that maven hang after the test has ended.
+
+ Some debugging shows that the maven-jmeter-plugin call to jmeter course
jmeter to leak threads,
+ I have done the following change to the maven-jmeter-plugin that fixes the
problem, using checkForEndOfTest method below.
+
+ Hope someone can use this to improve the plugin.
+
+ Code changes to org.apache.jmeter.JMeterMojo.java:
+
+ {{{
+ private void executeTest(File test) throws MojoExecutionException {
+ /...cut out from mail
+ try {
+ // This mess is necessary because the only way
to know when JMeter
+ // is done is to wait for all of the threads
that it spawned to exit.
+ new JMeter().start(args.toArray(new
String[]{}));
+ BufferedReader in = new BufferedReader(new
FileReader(jmeterLog));
+ while (!checkForEndOfTest(in)) {
+ try {
+ Thread.sleep(1000);
+ } catch (InterruptedException e) {
+ break;
+ }
+ }
+ in.close();
+ } catch (ExitException e) {
+ if (e.getCode() != 0) {
+ throw new MojoExecutionException("Test
failed", e);
+ }
+ } finally {
+ System.setSecurityManager(oldManager);
+
Thread.setDefaultUncaughtExceptionHandler(oldHandler);
+ }
+ } catch (IOException e) {
+ throw new MojoExecutionException("Can't execute test",
e);
+ }
+ }
+
+ private boolean checkForEndOfTest(BufferedReader in) throws
MojoExecutionException {
+ boolean testEnded = false;
+ try {
+ String line;
+ while ( (line = in.readLine()) != null) {
+ if (line.indexOf("Test has ended") != -1) {
+ testEnded = true;
+ break;
+ }
+ }
+ } catch (IOException e) {
+ throw new MojoExecutionException("Can't read log file",
e);
+ }
+ return testEnded;
+ }
+
+
+ }}}
+
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-jmeter Wiki] Update of "FrontPage" by JMeterAdmin
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jakarta-jmeter Wiki" for change notification. The following page has been changed by JMeterAdmin: http://wiki.apache.org/jakarta-jmeter/FrontPage The comment on the change is: Put links in more appropriate place -- * [http://blog.milamberspace.net/index.php/jmeter-test-de-charges-dun-site-web-mode-demploi Website load tests with JMeter (in french)] and [http://blog.milamberspace.net/index.php/jmeter-pages Several articles/tutorials (in french)] * [http://wiki.apache.org/jakarta-jmeter/JSF_test_with_SUN_implementation Testing a SUN RI JSF Application with JMeter] * [http://www.packtpub.com/beginning-apache-jmeter/book Apache JMeter book | Packt Publishing, June 2008] + * ["JMeterTesting/ASPNETViewState"] * General Articles on Performance testing etc. * [:HowManyThreads:How many threads does JMeter support?] @@ -44, +45 @@ * BrowserAddons - browser tools to show HTTP headers, etc. * NetworkSniffer - tools to capture HTTP Requests + + * ["JMeterMavenPlugin"] - user-contributed plugin for running JMeter in Maven * MonitoringServers - tools to monitor servers @@ -99, +102 @@ * ["JMeterGuiTestElementSeparation"] - * ["JMeterMavenPlugin"] - - * ["JMeterTesting/ASPNETViewState"] CategoryHomepage - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-jmeter Wiki] Update of "HowManyThreads" by JMeterAdmin
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jakarta-jmeter Wiki" for change notification. The following page has been changed by JMeterAdmin: http://wiki.apache.org/jakarta-jmeter/HowManyThreads The comment on the change is: Expand re load generation -- = How many threads does JMeter support? = - This depends on the test plan and the number of listeners, but users have reported successfully runnin 1000 threads in a single JMeter instance. + This depends on the test plan and the number of listeners, but users have reported successfully running 1000 threads in a single JMeter instance. See for example this e-mail thread: http://markmail.org/message/7hqxvchxlt755qb7 See also JMeter best practices: http://jakarta.apache.org/jmeter/usermanual/best-practices.html#lean_mean + Also, note that JMeter can place a much higher load on a system than a human user can, as it can make requests much faster. Suppose an average user waits 10 seconds between clicking links. With a wait time of 1 second, JMeter could generate 10 times the load. + + So a single JMeter thread can be the equivalent of 10 or more users, at least in terms of number of requests per second. + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 46007] WebServices responses are always 200
https://issues.apache.org/bugzilla/show_bug.cgi?id=46007 CES <[EMAIL PROTECTED]> changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #2 from CES <[EMAIL PROTECTED]> 2008-10-17 08:21:02 PST --- I want to add something. I believe that this is a JMeter bug. The server http response code is 500, don't care about the content. And JMeter result shows me that the http response code is 200. I use the proxy debugger to see the real response of the server. The proxy is not causing the error. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 46008] WebServices bodies from a folder. The result listener shows a empty body request
https://issues.apache.org/bugzilla/show_bug.cgi?id=46008 CES <[EMAIL PROTECTED]> changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Comment #2 from CES <[EMAIL PROTECTED]> 2008-10-17 08:30:53 PST --- I was referring to load the content from a folder, not from a file. So, when I watch the results I need to correlate each request with its correspondent file (body, parameters, etc.). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 46007] WebServices responses are always 200
https://issues.apache.org/bugzilla/show_bug.cgi?id=46007 Sebb <[EMAIL PROTECTED]> changed: What|Removed |Added Status|REOPENED|NEEDINFO --- Comment #3 from Sebb <[EMAIL PROTECTED]> 2008-10-17 09:21:43 PST --- I see now, I misunderstood your original report. Are you using the WebServices (SOAP) sampler or the SOAP/XML-RPC sampler? Can you provide a simple test case? If so, please add this as an attachment, or descibe how to generate the error. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 46008] WebServices bodies from a folder. The result listener shows a empty body request
https://issues.apache.org/bugzilla/show_bug.cgi?id=46008 Sebb <[EMAIL PROTECTED]> changed: What|Removed |Added Status|REOPENED|NEEDINFO --- Comment #3 from Sebb <[EMAIL PROTECTED]> 2008-10-17 09:28:12 PST --- Folder or file, there's no point in storing the content in the sample result as the data is available on disk. I've not used the folder option, so I don't know how it shows up in the GUI, but it would seem reasonable to store the file name that was chosen. Would that meet your needs? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
