Fix broken code blocks on the issue new tokens per request pages

en/identity-server/5.11.0/docs/learn/issuing-new-tokens-per-request.md

@@ -7,11 +7,11 @@
 This feature issues a new access token and refresh token for each token
 request after revoking the existing active token.
 
 ### Try it out
 
 Add the following configuration to the `         deployment.toml        ` file in
 `         <is_home>/repository/conf/        ` to enable issuing
 a new token per request `         .        `
 
 ``` java
 [oauth.token_renewal] 
@@ -22,13 +22,13 @@
     If the [OAuthTokenGenerator extension
     point](../../learn/extension-points-for-oauth)
     is used, it overrides the value of
     `         renew_access_token_per_request        ` . Here, the code level changes
     take precedence over our configuration change. Hence, this configuration
     will not affect the flow of self-contained access tokens, which by
     default renew access tokens for every request. This will not affect the
     flow of the refresh token grant type either, which renews the access
     token by default, and the refresh token depending on the
     `         renew_access_token_per_request        ` configuration in the
     `         deployment.toml        ` file.
 
 
@@ -50,7 +50,9 @@
 
 Given below are the responses to the first and the second requests.
 
-``` java tab="Response to the first call"
+**Response to the first call**
+
+``` java
 {
 "access_token": "ed074839-7efc-3c07-a5a0-a06382eba5ac",
 "refresh_token": "faecb739-b065-305e-8233-fa2e9d94c10e",
@@ -60,7 +62,9 @@
 }
 ```
 
-``` java tab="Response to the second call"
+**Response to the second call**
+
+``` java
 {
 "access_token": "1f00293e-278e-3326-89e3-eef2fcbf8b6b",
 "refresh_token": "c9deea6f-a440-35bf-8fac-e0a6043df2b1",
@@ -73,10 +77,14 @@
 You can also introspect the old access token using the following cURL
 command. You can see that it is inactive now.
 
-``` java tab="Request"
-curl -k -u admin:admin -H 'Content-Type: application/x-www-form-urlencoded' -X POST --data 'token=<access token from 1st token API call>'https://localhost:9443/oauth2/introspect
+**Request**
+
+``` java
+curl -k -u admin:admin -H 'Content-Type: application/x-www-form-urlencoded' -X POST --data 'token=<access token from 1st token API call>' https://localhost:9443/oauth2/introspect
 ```
 
-``` java tab="Response"
+**Response**
+
+``` java
 {'active':false}
 ```

en/identity-server/6.0.0/docs/guides/access-delegation/issue-new-tokens-per-request.md

@@ -41,19 +41,25 @@ renew_access_token_per_request = true
 Once you have created an OAuth application in WSO2 Identity Server and obtained its Client ID and Client Secret, you can generate
 the tokens by mentioning the password grant type in the cURL command given below.
 
-``` java tab="Request Format"
+**Request Format**
+
+``` java
 curl -v -X POST -H "Authorization: Basic <base64encoded clientId:clientSecrect>" -k -d "grant_type=password&username=<username>&password=<password>&scope=<scope>" -H "Content-Type:application/x-www-form-urlencoded" https://localhost:9443/oauth2/token
 ```
 
-``` java tab="Sample Request"
+**Sample Request**
+
+``` java
 curl -v -X POST -H "Authorization: Basic <base64encoded clientId:clientSecrect>" -k -d "grant_type=password&username=admin&password=admin&scope=openid" -H "Content-Type:application/x-www-form-urlencoded" https://localhost:9443/oauth2/token
 ```
 
 When you call the above URL for the second time, a new token is generated. As long as it's the same client ID, user, and scope, a new token is generated regardless of which grant type you use in the second call.
 
 Given below are sample responses to the first and the second requests.
 
-``` java tab="Response to the first call"
+**Response to the first call**
+
+``` java
 {
 "access_token": "ed074839-7efc-3c07-a5a0-a06382eba5ac",
 "refresh_token": "faecb739-b065-305e-8233-fa2e9d94c10e",
@@ -63,7 +69,9 @@ Given below are sample responses to the first and the second requests.
 }
 ```
 
-``` java tab="Response to the second call"
+**Response to the second call**
+
+``` java
 {
 "access_token": "1f00293e-278e-3326-89e3-eef2fcbf8b6b",
 "refresh_token": "c9deea6f-a440-35bf-8fac-e0a6043df2b1",
@@ -75,10 +83,14 @@ Given below are sample responses to the first and the second requests.
 
 You can also introspect the old access token using the following cURL command. You can see that it is inactive now.
 
-``` java tab="Request"
-curl -k -u admin:admin -H 'Content-Type: application/x-www-form-urlencoded' -X POST --data 'token=<access token from 1st token API call>'https://localhost:9443/oauth2/introspect
+**Request**
+
+``` java
+curl -k -u admin:admin -H 'Content-Type: application/x-www-form-urlencoded' -X POST --data 'token=<access token from 1st token API call>' https://localhost:9443/oauth2/introspect
 ```
 
-``` java tab="Response"
+**Response**
+
+``` java
 {'active':false}
 ```

en/identity-server/6.1.0/docs/guides/access-delegation/issue-new-tokens-per-request.md

@@ -41,19 +41,25 @@ renew_access_token_per_request = true
 Once you have created an OAuth application in WSO2 Identity Server and obtained its Client ID and Client Secret, you can generate
 the tokens by mentioning the password grant type in the cURL command given below.
 
-``` java tab="Request Format"
+**Request Format**
+
+``` java
 curl -v -X POST -H "Authorization: Basic <base64encoded clientId:clientSecrect>" -k -d "grant_type=password&username=<username>&password=<password>&scope=<scope>" -H "Content-Type:application/x-www-form-urlencoded" https://localhost:9443/oauth2/token
 ```
 
-``` java tab="Sample Request"
+**Sample Request**
+
+``` java
 curl -v -X POST -H "Authorization: Basic <base64encoded clientId:clientSecrect>" -k -d "grant_type=password&username=admin&password=admin&scope=openid" -H "Content-Type:application/x-www-form-urlencoded" https://localhost:9443/oauth2/token
 ```
 
 When you call the above URL for the second time, a new token is generated. As long as it's the same client ID, user, and scope, a new token is generated regardless of which grant type you use in the second call.
 
 Given below are sample responses to the first and the second requests.
 
-``` java tab="Response to the first call"
+**Response to the first call**
+
+``` java
 {
 "access_token": "ed074839-7efc-3c07-a5a0-a06382eba5ac",
 "refresh_token": "faecb739-b065-305e-8233-fa2e9d94c10e",
@@ -63,7 +69,9 @@ Given below are sample responses to the first and the second requests.
 }
 ```
 
-``` java tab="Response to the second call"
+**Response to the second call**
+
+``` java
 {
 "access_token": "1f00293e-278e-3326-89e3-eef2fcbf8b6b",
 "refresh_token": "c9deea6f-a440-35bf-8fac-e0a6043df2b1",
@@ -75,10 +83,14 @@ Given below are sample responses to the first and the second requests.
 
 You can also introspect the old access token using the following cURL command. You can see that it is inactive now.
 
-``` java tab="Request"
-curl -k -u admin:admin -H 'Content-Type: application/x-www-form-urlencoded' -X POST --data 'token=<access token from 1st token API call>'https://localhost:9443/oauth2/introspect
+**Request**
+
+``` java
+curl -k -u admin:admin -H 'Content-Type: application/x-www-form-urlencoded' -X POST --data 'token=<access token from 1st token API call>' https://localhost:9443/oauth2/introspect
 ```
 
-``` java tab="Response"
+**Response**
+
+``` java
 {'active':false}
 ```