Re: svn commit: r1784506 - in /jmeter/trunk: build.xml src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPJavaImpl.java xdocs/changes.xml

[Philippe Mouawad]

Done.
Thanks

On Mon, Feb 27, 2017 at 12:56 PM, sebb  wrote:

> On 27 February 2017 at 11:26, Philippe Mouawad
>  wrote:
> > On Mon, Feb 27, 2017 at 11:17 AM, sebb  wrote:
> >
> >> On 27 February 2017 at 07:57,   wrote:
> >> > Author: pmouawad
> >> > Date: Mon Feb 27 07:57:43 2017
> >> > New Revision: 1784506
> >> >
> >> > URL: http://svn.apache.org/viewvc?rev=1784506&view=rev
> >> > Log:
> >> > Bug 60778 - Http Java Impl does not show Authorization header in
> >> SampleResult even if it is sent
> >> > Bugzilla Id: 60778
> >> >
> >> > Modified:
> >> > jmeter/trunk/build.xml
> >> > jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/
> >> http/sampler/HTTPJavaImpl.java
> >> > jmeter/trunk/xdocs/changes.xml
> >> >
> >> > Modified: jmeter/trunk/build.xml
> >> > URL: http://svn.apache.org/viewvc/jmeter/trunk/build.xml?rev=1784
> >> 506&r1=1784505&r2=1784506&view=diff
> >> > 
> >> ==
> >> > --- jmeter/trunk/build.xml (original)
> >> > +++ jmeter/trunk/build.xml Mon Feb 27 07:57:43 2017
> >> > @@ -2739,6 +2739,13 @@ run JMeter unless all the JMeter jars ar
> >> >
> >> >  
> >> >
> >> > +   
> >> > +  
> >> > +  
> >> > +  value="jmeter.httpsampler"/>
> >> > + 
> >> > +
> >> > +
> >> >  
> >> >
> >> >
> >> >
> >> > Modified: jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/
> >> http/sampler/HTTPJavaImpl.java
> >> > URL: http://svn.apache.org/viewvc/jmeter/trunk/src/protocol/http/
> >> org/apache/jmeter/protocol/http/sampler/HTTPJavaImpl.
> >> java?rev=1784506&r1=1784505&r2=1784506&view=diff
> >> > 
> >> ==
> >> > --- jmeter/trunk/src/protocol/http/org/apache/jmeter/
> protocol/http/sampler/HTTPJavaImpl.java
> >> (original)
> >> > +++ jmeter/trunk/src/protocol/http/org/apache/jmeter/
> protocol/http/sampler/HTTPJavaImpl.java
> >> Mon Feb 27 07:57:43 2017
> >> > @@ -26,6 +26,7 @@ import java.net.InetSocketAddress;
> >> >  import java.net.Proxy;
> >> >  import java.net.URL;
> >> >  import java.net.URLConnection;
> >> > +import java.util.HashMap;
> >> >  import java.util.List;
> >> >  import java.util.Map;
> >> >  import java.util.zip.GZIPInputStream;
> >> > @@ -63,7 +64,6 @@ public class HTTPJavaImpl extends HTTPAb
> >> >
> >> >  static {
> >> >  log.info("Maximum connection retries = {}",
> MAX_CONN_RETRIES);
> >> // $NON-NLS-1$
> >> > -// Temporary copies, so can set the final ones
> >> >  }
> >> >
> >> >  private static final byte[] NULL_BA = new byte[0];// can share
> these
> >> > @@ -183,6 +183,9 @@ public class HTTPJavaImpl extends HTTPAb
> >> >  // with the last request to an HTTP server. Instead, most
> >> browsers
> >> >  // leave it to the server to close the connection after their
> >> >  // timeout period. Leave it to the JMeter user to decide.
> >> > +// Ensure System property "" is set to true to allow headers
> >>
> >> Missing property name
> >>
> > Good catch , fixed
> >
> >>
> >> > +// such as "Host" and "Connection" to be passed through.
> >> > +// See http://bugs.java.com/bugdataba
> >> se/view_bug.do?bug_id=6996110
> >> >  if (getUseKeepAlive()) {
> >> >  conn.setRequestProperty(HTTPConstants.HEADER_CONNECTION,
> >> HTTPConstants.KEEP_ALIVE);
> >> >  } else {
> >> > @@ -193,7 +196,7 @@ public class HTTPJavaImpl extends HTTPAb
> >> >  setConnectionHeaders(conn, u, getHeaderManager(),
> >> getCacheManager());
> >> >  String cookies = setConnectionCookie(conn, u,
> >> getCookieManager());
> >> >
> >> > -setConnectionAuthorization(conn, u, getAuthManager());
> >> > +Map securityHeaders =
> >> setConnectionAuthorization(conn, u, getAuthManager());
> >> >
> >> >  if (method.equals(HTTPConstants.POST)) {
> >> >  setPostHeaders(conn);
> >> > @@ -202,7 +205,7 @@ public class HTTPJavaImpl extends HTTPAb
> >> >  }
> >> >
> >> >  if (res != null) {
> >> > -res.setRequestHeaders(getConnectionHeaders(conn));
> >> > +res.setRequestHeaders(getConnectionHeaders(conn,
> >> securityHeaders));
> >> >  res.setCookies(cookies);
> >> >  }
> >> >
> >> > @@ -383,9 +386,10 @@ public class HTTPJavaImpl extends HTTPAb
> >> >   * @param conn
> >> >   *HttpUrlConnection which represents the
> >> URL
> >> >   *request
> >> > + * @param securityHeaders Map of security Header or null
> >> >   * @return the headers as a string
> >> >   */
> >> > -private String getConnectionHeaders(HttpURLConnection conn) {
> >> > +private String getConnectionHeaders(HttpURLConnection conn,
> >> Map securityHeaders) {
> >> >  // Get all the request properties, which are the headers set
> on
> >> the connection
> >> >  String

Re: HTTP Request : What to do with the Parameters tab entries for every method (was HTTP Request : Behaviour of PUT)

[Philippe Mouawad]

Hello,
Any thought on this one ?
Thanks

On Tue, Feb 28, 2017 at 10:46 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

> Hello,
> As per sebb will, I open a new discussion to decide:
> 1) what to do for each method
> 2) Which one takes precedence
>
> Regards
> Philippe
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: MultiPart/form-data : Supporting JSON body + file upload

[Philippe Mouawad]

Hello,
Any idea on this one ?
Thanks

On Wed, Mar 1, 2017 at 10:36 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

> Hello,
> Recent JS libraries (Angular + ng-file-upload for example) allow posting a
> request with:
> - Parameters  that contains JSON
> - 1 or more files
>
> See:
> https://github.com/danialfarid/ng-file-upload#upload-service
>
> {file: file, info: Upload.jsonBlob({id: id, name: name, ...})} send fields as 
> json blob, 'application/json' content_type
>
> POST /demo/model HTTP/1.1
> Connection: keep-alive
> Accept-Language: en-US,en;q=0.5
> Cache-Control: no-cache
> Accept-Encoding: gzip, deflate
> Pragma: no-cache
> User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 
> Firefox/51.0
> Accept: application/json, text/plain, */*
> Content-Length: 9145
> Content-Type: multipart/form-data; 
> boundary=cP4hM4kXJ134rNoUFiCCjcKhk4uzVlZAnFYBdQ; charset=UTF-8
> Host: localhost:8081
>
> --cP4hM4kXJ134rNoUFiCCjcKhk4uzVlZAnFYBdQ
> Content-Disposition: form-data; name="file"; filename="jmeter.png"
> Content-Type: image/png
>
> ‰PNG
> binary data here ...
>
> --cP4hM4kXJ134rNoUFiCCjcKhk4uzVlZAnFYBdQ
> Content-Disposition: form-data; name="info"; filename="dem_modele.json"
> *Content-Type: application/json*
>
> {"modelRequestDTO":{"userTranslation":"dfdfdfd","defaultTranslation":"dfdfdfdfd"},"userDescription":"dfdfdfdfdfdf"}
> --cP4hM4kXJ134rNoUFiCCjcKhk4uzVlZAnFYBdQ--
>
>
>
> Simulating this in JMeter is not very easy as you need to use the 3rd tab
> and put the json body in a file.
>
> This make variabilization of JSON content difficult.
>
> Ideally It would be much better if parameters table could be used,
> but it doesn't work as you cannot set Content-Type for parameters.
>
> How could we implement such case in the GUI ?:
>
> - Add a new column that would only be used in some case ? not very nice? How 
> would we decide wether we use it or not ?
>
> - Create some new Component (ParameterContentTypeSetter) that would tell 
> HttpRequest the Content-Type of each parameter
>
> by its name ?
>
> - Any other ideas ?
>
> Thanks
>
> Regards
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: svn commit: r1763904 - /jmeter/trunk/xdocs/stylesheets/site_printable.vsl

[sebb]

On 3 March 2017 at 18:24, Felix Schumacher
 wrote:
> Am 03.03.2017 um 19:20 schrieb sebb:
>>
>> On 3 March 2017 at 18:07, Felix Schumacher
>>  wrote:
>>>
>>> Am 03.03.2017 um 18:51 schrieb sebb:

 On 1 March 2017 at 17:37, Felix Schumacher
  wrote:
>
> Am 01.03.2017 um 14:00 schrieb sebb:
>>
>> On 8 October 2016 at 16:26,   wrote:
>>>
>>> Author: fschumacher
>>> Date: Sat Oct  8 15:26:31 2016
>>> New Revision: 1763904
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1763904&view=rev
>>> Log:
>>> Apply stylesheet recursively to code and source elements.
>>
>> -1
>>
>> Just discovered that this has broken several pages, for example
>>
>> get-started.html
>> 1.4.7 Logging and error messages
>
> I have applied a fix. I think it is OK now.

 There's still an issue - most of the  blocks now have spurious
 spaces or line-breaks.
 This messes up the layout.

 It's particularly noticeable for properties reference 20.22  - the
 'mode' description

 Also the code items on that page have leading and/or trailing spaces
 which look odd.
>>>
>>> That's nothing new. Look at any link. The link will be too wide, which
>>> looks
>>> odd. Same for bold or other emphasized text fragments. That is one
>>> reason,
>>> why I would like to get rid of vsl.
>>>
 I think the change should be reverted for both  and .
>>>
>>> That would mean, that we would have to change the documentation, as there
>>> are code/source elements, that have embedded other elements. Those would
>>> not
>>> work any more (and have been the reason for the original change).
>>>
>>> I will have a look at it.
>>>
>>> Most probably the macros would have to be written with less spaces in
>>> between them.
>>
>> That would help, but is going to be tedious.
>>
>> Or we don't allow embedded elements in code and/or source?
>> Are there many occurrences of these?
>>
>> A hack would be to have two versions - the original and the new one
>> that uses runloop.
>
> Have a look at r1785358, I hope it satisfies you (at least for the moment).
> The strange new lines in 20.22 are gone. As a plus, the links are shortened,
> also.
>
> The trick is to put comments at the end of lines, that are not really line
> endings. The comment for velocity seems to be "##".

Thanks, that looks fine.

> Felix
>
>>
>>> Regards,
>>>   Felix
>>>
 The subsequent fix (r1785002) seems OK.

> Thanks for spotting this.
>Felix
>
>>> Modified:
>>>jmeter/trunk/xdocs/stylesheets/site_printable.vsl
>>>
>>> Modified: jmeter/trunk/xdocs/stylesheets/site_printable.vsl
>>> URL:
>>>
>>>
>>> http://svn.apache.org/viewvc/jmeter/trunk/xdocs/stylesheets/site_printable.vsl?rev=1763904&r1=1763903&r2=1763904&view=diff
>>>
>>>
>>>
>>> ==
>>> --- jmeter/trunk/xdocs/stylesheets/site_printable.vsl (original)
>>> +++ jmeter/trunk/xdocs/stylesheets/site_printable.vsl Sat Oct  8
>>> 15:26:31
>>> 2016
>>> @@ -133,7 +133,7 @@ $value.content
>>> #end
>>>
>>> #macro ( code $value)
>>> -$escape.getText($value.getText())
>>> +#runloop($value)
>>> #end
>>>
>>> #macro ( source $value)
>>> @@ -146,7 +146,7 @@ $value.content
>>> 
>>> 
>>> >> width="1"
>>> height="1" vspace="0" hspace="0" border="0"/>
>>> ->> bgcolor="#ff">$escape.getText($value.getText())
>>> +#runloop($value)
>>> >> width="1"
>>> height="1" vspace="0" hspace="0" border="0"/>
>>> 
>>> 
>>>
>>>
>

Re: svn commit: r1763904 - /jmeter/trunk/xdocs/stylesheets/site_printable.vsl

[Felix Schumacher]

Am 03.03.2017 um 19:20 schrieb sebb:

On 3 March 2017 at 18:07, Felix Schumacher
 wrote:

Am 03.03.2017 um 18:51 schrieb sebb:

On 1 March 2017 at 17:37, Felix Schumacher
 wrote:

Am 01.03.2017 um 14:00 schrieb sebb:

On 8 October 2016 at 16:26,   wrote:

Author: fschumacher
Date: Sat Oct  8 15:26:31 2016
New Revision: 1763904

URL: http://svn.apache.org/viewvc?rev=1763904&view=rev
Log:
Apply stylesheet recursively to code and source elements.

-1

Just discovered that this has broken several pages, for example

get-started.html
1.4.7 Logging and error messages

I have applied a fix. I think it is OK now.

There's still an issue - most of the  blocks now have spurious
spaces or line-breaks.
This messes up the layout.

It's particularly noticeable for properties reference 20.22  - the
'mode' description

Also the code items on that page have leading and/or trailing spaces
which look odd.

That's nothing new. Look at any link. The link will be too wide, which looks
odd. Same for bold or other emphasized text fragments. That is one reason,
why I would like to get rid of vsl.


I think the change should be reverted for both  and .

That would mean, that we would have to change the documentation, as there
are code/source elements, that have embedded other elements. Those would not
work any more (and have been the reason for the original change).

I will have a look at it.

Most probably the macros would have to be written with less spaces in
between them.

That would help, but is going to be tedious.

Or we don't allow embedded elements in code and/or source?
Are there many occurrences of these?

A hack would be to have two versions - the original and the new one
that uses runloop.
Have a look at r1785358, I hope it satisfies you (at least for the 
moment). The strange new lines in 20.22 are gone. As a plus, the links 
are shortened, also.


The trick is to put comments at the end of lines, that are not really 
line endings. The comment for velocity seems to be "##".


Felix



Regards,
  Felix


The subsequent fix (r1785002) seems OK.


Thanks for spotting this.
   Felix


Modified:
   jmeter/trunk/xdocs/stylesheets/site_printable.vsl

Modified: jmeter/trunk/xdocs/stylesheets/site_printable.vsl
URL:

http://svn.apache.org/viewvc/jmeter/trunk/xdocs/stylesheets/site_printable.vsl?rev=1763904&r1=1763903&r2=1763904&view=diff


==
--- jmeter/trunk/xdocs/stylesheets/site_printable.vsl (original)
+++ jmeter/trunk/xdocs/stylesheets/site_printable.vsl Sat Oct  8
15:26:31
2016
@@ -133,7 +133,7 @@ $value.content
#end

#macro ( code $value)
-$escape.getText($value.getText())
+#runloop($value)
#end

#macro ( source $value)
@@ -146,7 +146,7 @@ $value.content



-$escape.getText($value.getText())
+#runloop($value)

Re: svn commit: r1763904 - /jmeter/trunk/xdocs/stylesheets/site_printable.vsl

[sebb]

On 3 March 2017 at 18:07, Felix Schumacher
 wrote:
> Am 03.03.2017 um 18:51 schrieb sebb:
>>
>> On 1 March 2017 at 17:37, Felix Schumacher
>>  wrote:
>>>
>>> Am 01.03.2017 um 14:00 schrieb sebb:

 On 8 October 2016 at 16:26,   wrote:
>
> Author: fschumacher
> Date: Sat Oct  8 15:26:31 2016
> New Revision: 1763904
>
> URL: http://svn.apache.org/viewvc?rev=1763904&view=rev
> Log:
> Apply stylesheet recursively to code and source elements.

 -1

 Just discovered that this has broken several pages, for example

 get-started.html
 1.4.7 Logging and error messages
>>>
>>> I have applied a fix. I think it is OK now.
>>
>> There's still an issue - most of the  blocks now have spurious
>> spaces or line-breaks.
>> This messes up the layout.
>>
>> It's particularly noticeable for properties reference 20.22  - the
>> 'mode' description
>>
>> Also the code items on that page have leading and/or trailing spaces
>> which look odd.
>
> That's nothing new. Look at any link. The link will be too wide, which looks
> odd. Same for bold or other emphasized text fragments. That is one reason,
> why I would like to get rid of vsl.
>
>>
>> I think the change should be reverted for both  and .
>
> That would mean, that we would have to change the documentation, as there
> are code/source elements, that have embedded other elements. Those would not
> work any more (and have been the reason for the original change).
>
> I will have a look at it.
>
> Most probably the macros would have to be written with less spaces in
> between them.

That would help, but is going to be tedious.

Or we don't allow embedded elements in code and/or source?
Are there many occurrences of these?

A hack would be to have two versions - the original and the new one
that uses runloop.

> Regards,
>  Felix
>
>>
>> The subsequent fix (r1785002) seems OK.
>>
>>> Thanks for spotting this.
>>>   Felix
>>>
> Modified:
>   jmeter/trunk/xdocs/stylesheets/site_printable.vsl
>
> Modified: jmeter/trunk/xdocs/stylesheets/site_printable.vsl
> URL:
>
> http://svn.apache.org/viewvc/jmeter/trunk/xdocs/stylesheets/site_printable.vsl?rev=1763904&r1=1763903&r2=1763904&view=diff
>
>
> ==
> --- jmeter/trunk/xdocs/stylesheets/site_printable.vsl (original)
> +++ jmeter/trunk/xdocs/stylesheets/site_printable.vsl Sat Oct  8
> 15:26:31
> 2016
> @@ -133,7 +133,7 @@ $value.content
>#end
>
>#macro ( code $value)
> -$escape.getText($value.getText())
> +#runloop($value)
>#end
>
>#macro ( source $value)
> @@ -146,7 +146,7 @@ $value.content
>
>
> width="1"
> height="1" vspace="0" hspace="0" border="0"/>
> - bgcolor="#ff">$escape.getText($value.getText())
> +#runloop($value)
> width="1"
> height="1" vspace="0" hspace="0" border="0"/>
>
>
>
>
>

Re: svn commit: r1763904 - /jmeter/trunk/xdocs/stylesheets/site_printable.vsl

[Felix Schumacher]

Am 03.03.2017 um 18:51 schrieb sebb:

On 1 March 2017 at 17:37, Felix Schumacher
 wrote:

Am 01.03.2017 um 14:00 schrieb sebb:

On 8 October 2016 at 16:26,   wrote:

Author: fschumacher
Date: Sat Oct  8 15:26:31 2016
New Revision: 1763904

URL: http://svn.apache.org/viewvc?rev=1763904&view=rev
Log:
Apply stylesheet recursively to code and source elements.

-1

Just discovered that this has broken several pages, for example

get-started.html
1.4.7 Logging and error messages

I have applied a fix. I think it is OK now.

There's still an issue - most of the  blocks now have spurious
spaces or line-breaks.
This messes up the layout.

It's particularly noticeable for properties reference 20.22  - the
'mode' description

Also the code items on that page have leading and/or trailing spaces
which look odd.
That's nothing new. Look at any link. The link will be too wide, which 
looks odd. Same for bold or other emphasized text fragments. That is one 
reason, why I would like to get rid of vsl.




I think the change should be reverted for both  and .
That would mean, that we would have to change the documentation, as 
there are code/source elements, that have embedded other elements. Those 
would not work any more (and have been the reason for the original change).


I will have a look at it.

Most probably the macros would have to be written with less spaces in 
between them.


Regards,
 Felix


The subsequent fix (r1785002) seems OK.


Thanks for spotting this.
  Felix


Modified:
  jmeter/trunk/xdocs/stylesheets/site_printable.vsl

Modified: jmeter/trunk/xdocs/stylesheets/site_printable.vsl
URL:
http://svn.apache.org/viewvc/jmeter/trunk/xdocs/stylesheets/site_printable.vsl?rev=1763904&r1=1763903&r2=1763904&view=diff

==
--- jmeter/trunk/xdocs/stylesheets/site_printable.vsl (original)
+++ jmeter/trunk/xdocs/stylesheets/site_printable.vsl Sat Oct  8 15:26:31
2016
@@ -133,7 +133,7 @@ $value.content
   #end

   #macro ( code $value)
-$escape.getText($value.getText())
+#runloop($value)
   #end

   #macro ( source $value)
@@ -146,7 +146,7 @@ $value.content
   
   
   
-$escape.getText($value.getText())
+#runloop($value)
   
   
   

Re: svn commit: r1763904 - /jmeter/trunk/xdocs/stylesheets/site_printable.vsl

[sebb]

On 1 March 2017 at 17:37, Felix Schumacher
 wrote:
> Am 01.03.2017 um 14:00 schrieb sebb:
>>
>> On 8 October 2016 at 16:26,   wrote:
>>>
>>> Author: fschumacher
>>> Date: Sat Oct  8 15:26:31 2016
>>> New Revision: 1763904
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1763904&view=rev
>>> Log:
>>> Apply stylesheet recursively to code and source elements.
>>
>> -1
>>
>> Just discovered that this has broken several pages, for example
>>
>> get-started.html
>> 1.4.7 Logging and error messages
>
> I have applied a fix. I think it is OK now.

There's still an issue - most of the  blocks now have spurious
spaces or line-breaks.
This messes up the layout.

It's particularly noticeable for properties reference 20.22  - the
'mode' description

Also the code items on that page have leading and/or trailing spaces
which look odd.

I think the change should be reverted for both  and .

The subsequent fix (r1785002) seems OK.

> Thanks for spotting this.
>  Felix
>
>>
>>> Modified:
>>>  jmeter/trunk/xdocs/stylesheets/site_printable.vsl
>>>
>>> Modified: jmeter/trunk/xdocs/stylesheets/site_printable.vsl
>>> URL:
>>> http://svn.apache.org/viewvc/jmeter/trunk/xdocs/stylesheets/site_printable.vsl?rev=1763904&r1=1763903&r2=1763904&view=diff
>>>
>>> ==
>>> --- jmeter/trunk/xdocs/stylesheets/site_printable.vsl (original)
>>> +++ jmeter/trunk/xdocs/stylesheets/site_printable.vsl Sat Oct  8 15:26:31
>>> 2016
>>> @@ -133,7 +133,7 @@ $value.content
>>>   #end
>>>
>>>   #macro ( code $value)
>>> -$escape.getText($value.getText())
>>> +#runloop($value)
>>>   #end
>>>
>>>   #macro ( source $value)
>>> @@ -146,7 +146,7 @@ $value.content
>>>   
>>>   
>>>   >> height="1" vspace="0" hspace="0" border="0"/>
>>> -$escape.getText($value.getText())
>>> +#runloop($value)
>>>   >> height="1" vspace="0" hspace="0" border="0"/>
>>>   
>>>   
>>>
>>>
>

Re: Possible Bug in Java 8 u 112 in javax.swing.JEditorPane.setText leads to stuck UI

[Philippe Mouawad]

Hello Muneer,
Thank you, but in JMeter we already do that before calling setText.
We still suffer from very bad (UI freezes for minutes taking 100% on on
CPU) response time.
Regards


On Wed, Mar 1, 2017 at 7:02 AM, Muneer Kolarkunnu <
abdul.kolarku...@oracle.com> wrote:

> Hi Philippe,
>
>
>
> If you set the content type before setting text, it is not taking much
> time. It is just 2-5 seconds.
>
> You can set the content type using 
> javax.swing.JEditorPane.setContentType(String)
> API.
>
> Eg: editor.setContentType("text/plain"); // or
> editor.setContentType("text/html");
>
>
>
> I updated the test case which you shared along with bug and attached.
>
>
>
> I hope it will resolve your issue.
>
>
>
> Regards,
>
> Muneer
>
>
>
> *From:* Philippe Mouawad [mailto:pmoua...@apache.org]
> *Sent:* Wednesday, March 01, 2017 3:29 AM
> *To:* Rory O'Donnell; Dalibor Topic
> *Cc:* Muneer Kolarkunnu; Balchandra Vaidya; dev@jmeter.apache.org
>
> *Subject:* Re: Possible Bug in Java 8 u 112 in javax.swing.JEditorPane.setText
> leads to stuck UI
>
>
>
> Hello Guys,
>
> Any chance that a P4 bug is fixed ?
>
> It unfortunately affects us badly whenever some text (more than 700K which
> is frequent for HTML pages) is received in our tool.
>
>
>
> For my information what does this mean:
> ILW = MLH = P4
>
> Thanks
>
>
>
> On Tue, Jan 31, 2017 at 12:26 PM, Rory O'Donnell 
> wrote:
>
> Hi Philippe,
>
> It's marked P4 because it is seen as a corner case issue.
>
> Rgds,Rory
> On 30/01/2017 22:43, Philippe Mouawad wrote:
>
> Hello,
> Thanks.
> Any chance issue gets fixed as I see it's P4 .
>
> Thank you
>
> On Monday, January 16, 2017, Muneer Kolarkunnu <
> abdul.kolarku...@oracle.com>
> wrote:
>
> Hi Philippe,
>
>
>
> Thanks for sharing standalone test case.
>
> Issue is reproducible in all platforms(Windows, Linux and Osx) with all
> JDK versions(7, 8, 9-ea).
>
> I reopened the bug, You can see the updates in here:
> https://bugs.openjdk.java.net/browse/JDK-8172336
>
>
>
> Regards,
>
> Muneer
>
>
>
> *From:* Philippe Mouawad [mailto:pmoua...@apache.org
> ]
> *Sent:* Sunday, January 15, 2017 4:33 AM
> *To:* Muneer Kolarkunnu
> *Cc:* Dalibor Topic; Balchandra Vaidya; dev@jmeter.apache.org
> ; Rory O'Donnell
> *Subject:* Re: Possible Bug in Java 8 u 112 in javax.swing.JEditorPane.
> setText
> leads to stuck UI
>
>
>
> Hi,
>
> Previous sample showed already very slow rendering when text contains
> spaces.
>
> Now for the text without space. Sample attached.
>
> Regards
>
>
>
> On Fri, Jan 13, 2017 at 2:20 PM, Philippe Mouawad  > wrote:
>
> Hello Muneer,
>
> Find attached  a simple program reproducing issue.
>
> I see you closed the bug
>
> Regards
>
>
>
> On Fri, Jan 6, 2017 at 2:28 PM, Muneer Kolarkunnu <
> abdul.kolarku...@oracle.com
> > wrote:
>
> Hi Philippe,
>
> Your incident has moved to JDK-8172336: https://bugs.openjdk.java.net/
> browse/JDK-8172336
>
> I tried to reproduce the issue, but I could not reproduce this issue with
> the information shared in the bug report. If you can provide a standalone
> test case, it will be great. Also, please let us know if you observe the
> same issue with JDK 8u122-ea and JDK 9-ea.
> Have you observed the same issue with other OS(Other than Mac OSX) ?
>
> 8u122-ea is available here : https://jdk8.java.net/download.html
> JDK 9-ea is available here : https://jdk9.java.net/download/
>
> Regards,
> Muneer
>
>
> -Original Message-
> From: Rory O'Donnell
> Sent: Thursday, January 05, 2017 5:22 PM
> To: dev@jmeter.apache.org
> 
> Cc: Rory O'Donnell; Dalibor Topic; Balchandra Vaidya; Muneer Kolarkunnu
> Subject: Re: Possible Bug in Java 8 u 112 in javax.swing.JEditorPane.
> setText
> leads to stuck UI
>
> Thanks Philippe, we'll take a look.
>
> Rgds,Rory
>
>
> On 05/01/2017 10:30, Philippe Mouawad wrote:
>
> Hello,
> Done:9046713
>
> Regards
>
> On Thu, Jan 5, 2017 at 11:14 AM, Rory O'Donnell
> 
> >
>
>
>
> wrote:
>
> Hi Philippe,
>
> Many happy returns!
>
> Can you log a bug and send us the Java Incident id ?
>
> Rgds,Rory
>
>
>
>
> On 05/01/2017 10:12, Philippe Mouawad wrote:
>
> Greetings,
> First best wishes for 2017.
>
> I'd like to report what seems to be a critical bug we face in JMeter
> . I noticed it under Mac OSX El Capitan.
>
> Calling javax.swing.JEditorPane.setText() from AWT Thread with some
> long text (without spaces) leads to what seems to be either a very
> long or infinite loop, I made thread dumps and I have always  such
> (partial)
> stacktrace:
> "AWT-EventQueue-0" #20 prio=6 os_prio=31 tid=0x7fa7a8afc000
> nid=0xf707 runnable [0x72202000]
>   java.lang.Thread.State: RUNNABLE
>at sun.font.CStrike.getNativeGlyphOutline(Native Method)
>at sun.font.CStrike.getGlyphOutline(CStrike.java:215)
>at sun.font.CStrike.getGlyphOutlineBounds(CStrike.java:177)
>at
> sun.font.StandardGlyphVector$GlyphStrike.getGlyphOutlineBoun
> ds(StandardGlyphVector.java:1792)
>at
> sun.font.StandardGlyphVector.getGlyphOutlineBounds(Sta

JDK 9 EA Build 159 and JDK 8u152 is available on java.net

[Rory O'Donnell]

Hi Philippe,

*JDK 8u152 **Early Access b01  *is 
available on java.net


*JDK 9 Early Access* b159   is 
available on java.net, summary of  changes are listed here 
.


There have been a number of fixes to bugs reported by Open Source 
projects since the last availability email  :


 * b159 - JDK-8175261 : Per-protocol cache setting not working for JAR
   URLConnection
 * b158 - JDK-8173028 : Incorrect processing of supplementary-plane
   characters in text fields
 * b158 - JDK-8172967 : [macosx] Exception while working with layout
   for text containing unmappable character
 * b158 - JDK-8173804 : javadoc throws UnsupportedOperationException:
   should not happen
 * b157 - JDK-8174073 : NPE caused by @link reference to class
 * b156 - JDK-8172726 : ForkJoin common pool retains a reference to the
   thread context class loader

The following changeset is included in jdk-9+158:
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8b0d55e02f54

If you have a user-defined Policy implementation that grants 
FilePermission on ${user.dir}/-, reading a file in the current directory 
using its base name will fail.  Still the same solution: Ensure that the 
path used in permission granting has the same style as the one how you 
access the file.


Setting -Djdk.security.filePermCompat=true will take you back to the 
jdk-9+140 behavior.
Setting -Djdk.io.permissionsUseCanonicalPath=true will take you back to 
the jdk8 behavior.

Feedback is welcome on jdk9-...@openjdk.java.net

Other areas of interest

 * JDK 9 Developer Guide [1]
 * JDK 9 Migration Guide [2]
 * JDK Cryptographic Roadmap [3]

Finaly, Dalibor and I gave a presentation at FOSDEM the video is 
available here [*4*]


Rgds,Rory

[1] http://docs.oracle.com/javase/9/javase-docs.htm
[2] 
https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-7744EF96-5899-4FB2-B34E-86D49B2E89B6

[3] https://www.java.com/en/jre-jdk-cryptoroadmap.html
[4] https://fosdem.org/2017/schedule/event/outreach/

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland