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 <[email protected]> Authored: Sun Dec 16 19:36:57 2018 -0500 Committer: Ryan McGuinness <[email protected]> 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.
