[15/21] tomee git commit: Updated HTML Tags to MetaTags

[jl...@apache.org]

Updated HTML Tags to MetaTags


Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/1803338d
Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/1803338d
Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/1803338d

Branch: refs/heads/master
Commit: 1803338de070a2d9d03cb22134d62ea425696268
Parents: 1d0c603
Author: Ryan McGuinness <ry...@homedepot.com>
Authored: Sun Dec 16 19:36:57 2018 -0500
Committer: Ryan McGuinness <ry...@homedepot.com>
Committed: Sun Dec 16 19:36:57 2018 -0500

----------------------------------------------------------------------
 examples/access-timeout-meta/README.adoc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/tomee/blob/1803338d/examples/access-timeout-meta/README.adoc
----------------------------------------------------------------------
diff --git a/examples/access-timeout-meta/README.adoc b/examples/access-timeout-meta/README.adoc
index 56494e6..5a30432 100644
--- a/examples/access-timeout-meta/README.adoc
+++ b/examples/access-timeout-meta/README.adoc
@@ -131,7 +131,7 @@ Once you create a few meta-annotations and the fun becomes common-place, questoi
 You have to really start thinking about how you want to approach your usage of meta-annotation and really put your designer hat on.  The fundamental question is
 **configuration vs operation** and the answer is subjective; how much flexibility do you want to design into your applications and where?
 
-## Configuration names <small>describing the configuration</small>
+## Configuration names [.small]#describing the configuration#
 
 The simplest approach is to name your meta-annotations after the **configuration** they encapsulate. We've been following that format so far with `@AwaitNever` and `@AwaitForever`
 to clearly reflect the contents of each meta-annotation (`@AccessTimeout(-1)` and `@AccessTimeout(0)` respectively).
@@ -139,7 +139,7 @@ to clearly reflect the contents of each meta-annotation (`@AccessTimeout(-1)` an
 The **cons** of this approach is that should you want to change the configuration of the application by only changing the meta-annotations -- this is one of the potential benefits
 of meta-annotations -- but this may change the meaning of the annotation.  Certainly, the `@AwaitNever` meta-annotation can have no other value than `0` if it is to live up to its name.
 
-## Operation names <small>describing the code</small>
+## Operation names [.small]describing the code#
 
 The alternate approach is to name your meta-annotations after the **operations** they apply to.  In short, to describe the code itself and not the configuration.  So, names like
 `@OrderCheckTimeout` or `@TwitterUpdateTimeout`.  These names are configuration-change-proof.  They would not change if the configuration changes and in fact they can facilitate
@@ -148,7 +148,7 @@ finder-grained control over the configuration of an application.
 The **cons** of this approach is that requires far more deliberation and consideration, not to mention more annotations.  Your skills as an architect, designer and ability to think as
 a administrator will be challenged.  You must be good at wearing your dev-opts hat.
 
-## Pragmatism  <small>best of both worlds</small>
+## Pragmatism  [.small]#best of both worlds#
 
 Fortunately, meta-annotations are recursive.  You can do a little of both.