This is an automated email from the ASF dual-hosted git repository.
rzo1 pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomee.git
The following commit(s) were added to refs/heads/main by this push:
new b8fc03c5be Improves highlighting by formatting important files in code
style: (#2514)
b8fc03c5be is described below
commit b8fc03c5becbe6139c23b60e1ee91801dd9316af
Author: Martin Wiesner <[email protected]>
AuthorDate: Sun Feb 22 21:12:35 2026 +0100
Improves highlighting by formatting important files in code style: (#2514)
- ejb-jar.xml
- openejb-jar.xml
- web.xml
- persistence.xml
to increase readability and dev's UX
Co-authored-by: Richard Zowalla <[email protected]>
---
docs/admin/configuration/resources.adoc | 2 +-
docs/alternate-descriptors.adoc | 8 +++----
docs/application-composer/history.adoc | 2 +-
docs/application-discovery-via-the-classpath.adoc | 10 ++++----
docs/built-in-type-converters.adoc | 6 ++---
docs/collapsed-ear.adoc | 4 ++--
docs/configuration.adoc | 2 +-
docs/configuring-datasources-in-tests.adoc | 2 +-
docs/configuring-persistenceunits-in-tests.adoc | 13 +++++-----
docs/custom-injection.adoc | 6 ++---
docs/datasource-config.adoc | 2 +-
docs/deploying-in-tomee.adoc | 2 +-
docs/deployment-id.adoc | 21 ++++++++--------
docs/deployments.adoc | 10 ++++----
docs/details-on-openejb-jar.adoc | 28 +++++++++++-----------
docs/developer/configuration/cxf.adoc | 2 +-
docs/ejb-refs.adoc | 6 ++---
docs/ejbd-transport.adoc | 4 ++--
docs/embedded-configuration.adoc | 2 +-
...l-testing-with-openejb,-jetty-and-selenium.adoc | 2 +-
docs/generating-ejb-3-annotations.adoc | 4 ++--
docs/hibernate.adoc | 2 +-
docs/jndi-names.adoc | 6 ++---
docs/jpa-usage.adoc | 2 +-
docs/lookup-of-other-ejbs-example.adoc | 4 ++--
docs/new-in-openejb-3.0.adoc | 6 ++---
docs/openejb-eclipse-plugin.adoc | 2 +-
docs/openjpa.adoc | 2 +-
docs/properties-listing.adoc | 2 +-
docs/resource-injection.adoc | 2 +-
docs/securing-a-web-service.adoc | 8 +++----
docs/singleton-beans.adoc | 2 +-
docs/spring-and-openejb-3.0.adoc | 2 +-
docs/spring.adoc | 2 +-
docs/tip-concurrency.adoc | 2 +-
docs/tomcat-object-factory.adoc | 2 +-
docs/tomee-and-eclipse.adoc | 4 ++--
docs/tomee-and-security.adoc | 2 +-
38 files changed, 95 insertions(+), 95 deletions(-)
diff --git a/docs/admin/configuration/resources.adoc
b/docs/admin/configuration/resources.adoc
index dd13e40753..4f3a80fccb 100644
--- a/docs/admin/configuration/resources.adoc
+++ b/docs/admin/configuration/resources.adoc
@@ -151,7 +151,7 @@ these functions yourself, set `JtaManaged` to `false`
==== DataSource and JPA
-In terms of JPA persistence.xml:
+In terms of JPA `persistence.xml`:
- `JtaManaged=true` can be used as a 'jta-data-source'
- `JtaManaged=false` can be used as a 'non-jta-data-source'
diff --git a/docs/alternate-descriptors.adoc b/docs/alternate-descriptors.adoc
index 879738626e..a782729c1a 100644
--- a/docs/alternate-descriptors.adoc
+++ b/docs/alternate-descriptors.adoc
@@ -14,7 +14,7 @@ or even a specific test.
Note that this approach was added as a catch-all for when one of the
simpler overriding techniques will not work. For the common case of
-needing to tweak your persistence.xml, see the
+needing to tweak your `persistence.xml`, see the
link:configuring-persistenceunits-in-tests.html[Configuring
PersistenceUnits in Tests] page for a simpler approach.
@@ -64,7 +64,7 @@ Note that there does _not_ have to be an equivalent
non-prefixed version
of the file. In the example above, only a "test.env-entry.properties"
file exists and there is no equivalent plain "env-entry.properties"
file. This prefixing works for any deployment descriptor in the
-META-INF/ directory or WEB-INF/ directory. The prefix does not have to
+`META-INF` directory or `WEB-INF` directory. The prefix does not have to
be "test" and could be anything you choose. You can also have as many
prefixed files as you need and could even go as far as to have one
prefix per individual test.
@@ -74,8 +74,8 @@ prefix per individual test.
It is possible to have several prefixes, specified in order of
preference, so that it is possible to avoid duplicating descriptors that
are used in more than one "profile". For example, the "foo" test case
-uses the same "env-entries.properties" file as the "bar" test case, but
-both have their own ejb-jar.xml files:
+uses the same `env-entries.properties` file as the "bar" test case, but
+both have their own `ejb-jar.xml` files:
* META-INF/ejb-jar.xml
* META-INF/test.ejb-jar.xml
diff --git a/docs/application-composer/history.adoc
b/docs/application-composer/history.adoc
index ea21bf32dc..3a3525bc87 100644
--- a/docs/application-composer/history.adoc
+++ b/docs/application-composer/history.adoc
@@ -30,7 +30,7 @@ ApplicationComposer "test" (browsing other pages you'll see
it is much
more than test today) is composed of mainly 2 parts:
* modules: methods describing a module of an application. It can be a
-persistence.xml, an ejb-jar.xml, a web.xml...but all programmatically.
+persistence.xml, an `ejb-jar.xml`, a `web.xml`...but all programmatically.
* configuration: container configuration allowing to interact with
container (creating resources for instance)
diff --git a/docs/application-discovery-via-the-classpath.adoc
b/docs/application-discovery-via-the-classpath.adoc
index add3ce219a..7d04e1a2d3 100644
--- a/docs/application-discovery-via-the-classpath.adoc
+++ b/docs/application-discovery-via-the-classpath.adoc
@@ -11,7 +11,7 @@ like deployed while in an embedded mode.
= Empty ejb-jar.xml approach (recommended)
Simplify the issue of searching for annotated applications by adding an
-ejb-jar.xml like this to your app:
+`ejb-jar.xml` like this to your app:
[source,xml]
----
@@ -21,7 +21,7 @@ ejb-jar.xml like this to your app:
OpenEJB will find the app in the classpath and deploy it along with any
annotated beans it may contain.
-The ejb-jar.xml can contain more than just "" as usual.
+The `ejb-jar.xml` can contain more than just "" as usual.
This is the recommended approach for people using OpenEJB for unit
testing as it allows OpenEJB to find your application in the classpath
@@ -30,10 +30,10 @@ complicate builds.
== Including/Excluding paths (advanced)
-If you do not like the idea of having the ejb-jar.xml in your app or an
+If you do not like the idea of having the `ejb-jar.xml` in your app or an
openejb.xml, we can search the classpath for annotated beans
(`@Stateless`, `@Stateful`, `@MessageDriven`) and load them automatically just
-as if they contained an ejb-jar.xml.
+as if they contained an `ejb-jar.xml`.
This form of searching, however, is very expensive as it involves
iterating over every path in the classpath and reading in each class
@@ -95,7 +95,7 @@ reversing the order to
__openejb.exclude-include.order__=exclude-include
There are a number of internal filters that may result in an unexpected
exclusion.
-If you're having trouble determining if the META-INF/ejb-jar.xml file
+If you're having trouble determining if the `META-INF/ejb-jar.xml` file
for your ejb module is in the classpath, a little debug code like this
in your test setup will help you see what OpenEJB sees (which may be
nothing):
diff --git a/docs/built-in-type-converters.adoc
b/docs/built-in-type-converters.adoc
index a3649b35e2..b5f72a88ec 100644
--- a/docs/built-in-type-converters.adoc
+++ b/docs/built-in-type-converters.adoc
@@ -5,8 +5,8 @@
:jbake-status: published
The following built-in types are supported for
-@Resource injection in EJBs via elements in a META-INF/ejb-jar.xml or
-via plain properties in a META-INF/env-entries.properties file.
+@Resource injection in EJBs via elements in a `META-INF/ejb-jar.xml` or
+via plain properties in a `META-INF/env-entries.properties` file.
EJB 3.0 required types:
@@ -74,7 +74,7 @@ public class MyBean {
}
----
-Works with an ejb-jar.xml as follows:
+Works with an `ejb-jar.xml` as follows:
[source,xml]
----
diff --git a/docs/collapsed-ear.adoc b/docs/collapsed-ear.adoc
index 35de8efacc..0728ccce11 100644
--- a/docs/collapsed-ear.adoc
+++ b/docs/collapsed-ear.adoc
@@ -9,10 +9,10 @@
The basic idea of this approach is that your Servlets and EJBs are
together in your WAR file as one app.
-* No classloader boundries between Servlets and EJBs
+* No classloader boundaries between Servlets and EJBs
* EJBs and Servlets can share all third-party libraries (like Spring!) -
no EAR required.
-* Can put the web.xml and ejb-jar.xml in the same archive (the WAR
+* Can put the `web.xml` and `ejb-jar.xml` in the same archive (the WAR
file).
* EJBs can see Servlet classes and vice versa.
diff --git a/docs/configuration.adoc b/docs/configuration.adoc
index 45743b2c15..c1e4140cc0 100644
--- a/docs/configuration.adoc
+++ b/docs/configuration.adoc
@@ -26,7 +26,7 @@ org.openejb.alt.assembler.classic.OpenEjbConfiguration object;
implements the
org.openejb.alt.assembler.classic.OpenEjbConfigurationFactory interface
* _openejb.descriptors.output_ - possible values: true|false - When set
-OpenEJB saves deployment descriptors - ejb-jar.xml and openejb-jar.xml
+OpenEJB saves deployment descriptors - `ejb-jar.xml` and `openejb-jar.xml`
== Configuration File
diff --git a/docs/configuring-datasources-in-tests.adoc
b/docs/configuring-datasources-in-tests.adoc
index 0f951664bd..56d3fee877 100644
--- a/docs/configuring-datasources-in-tests.adoc
+++ b/docs/configuring-datasources-in-tests.adoc
@@ -51,7 +51,7 @@ full list of supported Resource types and their properties.
== Note on <jta-data-source> and <non-jta-data-source>
-When configuring DataSources to be used by persistence.xml files, the
+When configuring DataSources to be used by `persistence.xml` files, the
DataSource supplied for `<jta-data-source>` is typically identical to
the `<non-jta-data-source>`, but with the `JtaManaged` property set
differently. Keeping with our philosophy to free you up from redundant
diff --git a/docs/configuring-persistenceunits-in-tests.adoc
b/docs/configuring-persistenceunits-in-tests.adoc
index 10bc1ea9f8..d772cf2e20 100644
--- a/docs/configuring-persistenceunits-in-tests.adoc
+++ b/docs/configuring-persistenceunits-in-tests.adoc
@@ -4,11 +4,10 @@
:jbake-type: page
:jbake-status: published
-= Overriding the
-persistence.xml
+= Overriding the persistence.xml
The most common situation in EJB related testing by far is the need to
-alter your persistence.xml for a test environment.
+alter your `persistence.xml` for a test environment.
== Overriding the jta-data-source and non-jta-data-source
@@ -18,11 +17,11 @@ you intend even if the names don't match exactly -- or in
some cases at
all. If there is only one DataSource configured, it's very easy for us
to guess the DataSource to use.
-This allows you to keep your persistence.xml configured for your
+This allows you to keep your `persistence.xml` configured for your
production environment and helps eliminate the need for a "test"
-persistence.xml (though we do have that functionality). A log line will
+`persistence.xml` (though we do have that functionality). A log line will
be printed saying if we had to adjust the DataSources of your
-persistence.xml.
+`persistence.xml`.
== Overriding the persistence-unit properties
@@ -31,7 +30,7 @@ properties or the initial context properties. The format is:
`<unit-name>.<property>=<value>`
-So for example with the following persistence.xml:
+So for example with the following `persistence.xml`:
[source,xml]
----
diff --git a/docs/custom-injection.adoc b/docs/custom-injection.adoc
index e6ff92f2bc..8b5ddc062f 100644
--- a/docs/custom-injection.adoc
+++ b/docs/custom-injection.adoc
@@ -8,11 +8,11 @@
As noted in the link:injection-of-env-entry-example.html[Injection of
env-entry Example] , the EJB 3.0 supported env-entry types are fairly
-limited. Also the use of several tags in an ejb-jar.xml can get a bit
+limited. Also the use of several tags in an `ejb-jar.xml` can get a bit
verbose.
OpenEJB does not restrict you to just these data types or require you to
-use an ejb-jar.xml to declare them.
+use an `ejb-jar.xml` to declare them.
* `@Resource` can be used on any type for which there is
`java.beans.PropertyEditor`
@@ -20,7 +20,7 @@ use an ejb-jar.xml to declare them.
app.
* Java Generics are supported (e.g. List myURIs)
* You may use a `META-INF/env-entries.properties` file as an alternative
-to an ejb-jar.xml
+to an `ejb-jar.xml`
See link:built-in-type-converters.html[Built-in Type Converters] for a
full list of supported env-entry types.
diff --git a/docs/datasource-config.adoc b/docs/datasource-config.adoc
index 82658348ad..680e188d9a 100644
--- a/docs/datasource-config.adoc
+++ b/docs/datasource-config.adoc
@@ -407,7 +407,7 @@ transactions. Calling begin/commit/rollback or
setAutoCommit on the
datasource or connection will not be allowed. If you need to perform
these functions yourself, set `JtaManaged` to `false`
-In terms of JPA persistence.xml:
+In terms of JPA `persistence.xml`:
* `JtaManaged=true` can be used as a 'jta-data-source'
* `JtaManaged=false` can be used as a 'non-jta-data-source'
diff --git a/docs/deploying-in-tomee.adoc b/docs/deploying-in-tomee.adoc
index de08316311..02eadbb26f 100644
--- a/docs/deploying-in-tomee.adoc
+++ b/docs/deploying-in-tomee.adoc
@@ -43,7 +43,7 @@ together in your WAR file as one application.
* No classloader boundaries between Servlets and EJBs
* EJBs and Servlets can share all third-party libraries (like Spring!)
* No EAR required.
-* Can put the web.xml and ejb-jar.xml in the same archive (the WAR file)
+* Can put the `web.xml` and `ejb-jar.xml` in the same archive (the WAR file)
* EJBs can see Servlet classes and vice versa
=== Not quite J2EE (But it is Java EE 6)
diff --git a/docs/deployment-id.adoc b/docs/deployment-id.adoc
index 005013752f..e782eed3ae 100644
--- a/docs/deployment-id.adoc
+++ b/docs/deployment-id.adoc
@@ -14,16 +14,16 @@ deployment id.
== Like ejb-name
-This deployment id is much like the element of the ejb-jar.xml , with
+This deployment id is much like the element of the `ejb-jar.xml`, with
one very important difference. The is only required to be unique within
-the scope of the ejb-jar.xml in the bean's jar. The deployment id is
+the scope of the `ejb-jar.xml` in the bean's jar. The deployment id is
required to be unique across all beans and jars in OpenEJB. This is a
subtle, but important, distinction.
Remember that the EJB specification was designed so that enterprise
beans could be created, packaged, and sold by vendors (EJB Providers).
Furthermore, users should be able to buy a packaged set of beans (a jar
-with an ejb-jar.xml in it) and deploy it into an EJB Container without
+with an `ejb-jar.xml` in it) and deploy it into an EJB Container without
modification.
== The ejb-name is not unique
@@ -32,12 +32,12 @@ Let's consider this, what happens if two vendors each sell
a package
(jar) that contains a bean with the PurchaseOrder? Both are completely
different in terms functionality and are different beans in every other
respect. The EJB spec says, this is fine, ejb-names only have to unique
-within the jar and that jar's ejb-jar.xml file. It's ridiculous to
+within the jar and that jar's `ejb-jar.xml` file. It's ridiculous to
expect EJB Providers to call each other up and ask, "Are you already
using the name 'PurchaseOrder' in your jar?" Remember that the EJB
specification was designed so that enterprise beans could be created,
packaged, and sold by vendors (EJB Providers). Furthermore, users should
-be able to buy a packaged set of beans (a jar with an ejb-jar.xml in it)
+be able to buy a packaged set of beans (a jar with an `ejb-jar.xml` in it)
and deploy it into an EJB Container without modification. This is all
fine and dandy, but it still leaves it up to the EJB Container/Server
providers to settle the difference.
@@ -81,7 +81,7 @@ Server.
For bean to bean communications, the Local Server must create a JNDI
namespace (JNDI ENC) for each bean as defined by the bean's , , and
-elements of the bean's ejb-jar.xml file. Every bean literally gets its
+elements of the bean's `ejb-jar.xml` file. Every bean literally gets its
very own JNDI namespace. When a bean makes a JNDI call, the Local Server
intercepts this call and uses the deployment id of the calling bean to
retrieve that bean's private JNDI namespace from the container system's
@@ -90,7 +90,7 @@ namespace.
All non-bean clients share one big global namespace. Since non-bean
clients are not deployed and do not have a deployment descriptor like an
-ejb-jar.xml, the Local Server is unable to taylor a namespace for each
+`ejb-jar.xml`, the Local Server is unable to taylor a namespace for each
non-bean client as it can for bean clients. The Local server cannot
identify non-bean clients as they have no deployment id. All JNDI calls
made by clients that the Local Server cannot identify go to the public,
@@ -117,9 +117,10 @@ javax.naming.NameNotFoundException.
In short...
-For beans: - Each bean has its own private, personalized JNDI namespace
-- The names in it are the same names it uses in its ejb-jar.xml - Beans
-can only access their private namespace, period
+For beans:
+- Each bean has its own private, personalized JNDI namespace
+- The names in it are the same names it uses in its `ejb-jar.xml`
+- Beans can only access their private namespace, period
For non-beans (everyone else): - Non-bean clients share the public,
global JNDI namespace - The names in it are the deployment ids of all
diff --git a/docs/deployments.adoc b/docs/deployments.adoc
index feb8b7c643..97d15dfd46 100644
--- a/docs/deployments.adoc
+++ b/docs/deployments.adoc
@@ -47,11 +47,11 @@ attribute pointing to the directory containing the jar
files.
----
The directories listed will be searched for jars containing
-'META-INF/ejb-jar.xml' files and will be added to the list of jars to
+`META-INF/ejb-jar.xml` files and will be added to the list of jars to
load if they do. Better said, it's completely safe to point to a
directory containing a mix of ejbs and regular jar files. TomEE will
simply skip over jars that do contain the required
-'META-INF/ejb-jar.xml' file.
+`META-INF/ejb-jar.xml` file.
The last Deployments element declares a 'beans' directory relative to
catalina.base for holding ejb jars. This declaration is simply convention
@@ -60,9 +60,9 @@ and not required.
== An unpacked jar
As of 1.0 beta1, TomEE supports unpacked ejb jars. Simply meaning that
-you don't need to pack your ejb's into a jar file in order to use them
+you don't need to pack your ejbs into a jar file in order to use them
in TomEE. You still need to follow the ejb jar layout and include an
-"META-INF/ejb-jar.xml" in the directory that contains your ejbs.
+`META-INF/ejb-jar.xml` in the directory that contains your ejbs.
For example, if you have a directory structure like this:
@@ -92,7 +92,7 @@ set to 'C:' as shown below.
----
Note that this syntax is the same as the directory syntax above. If
-TomEE finds a META-INF directory with an 'ejb-jar.xml' fine inside,
+TomEE finds a META-INF directory with an `ejb-jar.xml` fine inside,
then TomEE will treat the directory as an unpacked ejb jar. Otherwise,
TomEE will look for ejb jar files to load as detailed in the above
section.
diff --git a/docs/details-on-openejb-jar.adoc b/docs/details-on-openejb-jar.adoc
index e39041c86a..bbaf9b58e8 100644
--- a/docs/details-on-openejb-jar.adoc
+++ b/docs/details-on-openejb-jar.adoc
@@ -8,39 +8,39 @@
= What is an openejb-jar.xml?
This is the file created by the Deploy Tool that maps your bean's
-deployment descriptor (ejb-jar.xml) to actual containers and resources
+deployment descriptor (`ejb-jar.xml`) to actual containers and resources
declared in your OpenEJB configuration (openejb.conf). In fact, the
Deploy tool really does nothing more than create this file and put it in
your jar, that's it.
= When is the openejb-jar.xml used?
-At startup, any jar containing an openejb-jar.xml is loaded by the
+At startup, any jar containing an `openejb-jar.xml` is loaded by the
container system. The configuration tools will go looking in all the
directories and jars you have declared in your openejb.conf with the
element. For every jar file it finds, it will look inside for an
-openejb-jar.xml. If it finds one, it will attempt to load and deploy it
+`openejb-jar.xml`. If it finds one, it will attempt to load and deploy it
into the container system.
= Do I even need the deploy tool then?
Nope. Typically, you would only use the deploy tool to create your
-openejb-jar.xml, then just keep your openejb-jar.xml in your CVS (or
-other repository). If you learn how to maintain this openejb-jar.xml
+`openejb-jar.xml`, then just keep your `openejb-jar.xml` in your CVS (or
+other repository). If you learn how to maintain this `openejb-jar.xml`
file, you'll never need the deploy tool again! You can do all your
builds and deploys automatically.
= Where do I put the openejb-jar.xml in my jar?
-The openejb-jar.xml file just goes in the META-INF directory of your jar
-next to the ejb-jar.xml file.
+The `openejb-jar.xml` file just goes in the `META-INF` directory of your jar
+next to the `ejb-jar.xml` file.
= Is the file format easy?
-If you can understand the ejb-jar.xml, the openejb-jar.xml should be a
+If you can understand the `ejb-jar.xml`, the `openejb-jar.xml` should be a
breeze.
-This is the openejb-jar.xml that is created by the Deploy tool in the
+This is the `openejb-jar.xml` that is created by the Deploy tool in the
Hello World example. As you can see, the file format is extremely
simple.
@@ -55,7 +55,7 @@ simple.
----
The _ejb-name_ attribute is the name you gave the bean in your
-ejb-jar.xml. The _deployment-id_ is the name you want to use to look up
+`ejb-jar.xml`. The _deployment-id_ is the name you want to use to look up
the bean in your client's JNDI namespace. The _container-id_ is the name
of the container in your openejb.conf file that you would like the bean
to run in. There MUST be one _ejb-deployment_ element for each EJB in
@@ -83,14 +83,14 @@ Then you simply add an element to your element like this
----
The _res-ref-name_ attribute refers to the element of the bean's
-declaration in the ejb-jar.xml. The _res-id_ attribute refers to the id
+declaration in the `ejb-jar.xml`. The _res-id_ attribute refers to the id
of the declared in your openejb.conf that will handle the connections
and provide access to the desired resource.
= How many resource-link elements will I need?
-You will need one element for every element in your ejb-jar.xml. So if
-you had an ejb-jar.xml like the following
+You will need one element for every element in your `ejb-jar.xml`. So if
+you had an `ejb-jar.xml` like the following
[source,xml]
----
@@ -128,7 +128,7 @@ you had an ejb-jar.xml like the following
</ejb-jar>
----
-Then you would need two elements for that bean in your openejb-jar.xml
+Then you would need two elements for that bean in your `openejb-jar.xml`
file as such.
[source,xml]
diff --git a/docs/developer/configuration/cxf.adoc
b/docs/developer/configuration/cxf.adoc
index 997fc82c5d..483ac65228 100644
--- a/docs/developer/configuration/cxf.adoc
+++ b/docs/developer/configuration/cxf.adoc
@@ -62,7 +62,7 @@ Databinding is simply either a qualified name or a service id
in resources.xml (
== Sample for JAX-WS
-To configure WSS4J on the EJB `CalculatorBean` for instance add in
openejb-jar.xml:
+To configure WSS4J on the EJB `CalculatorBean` for instance add in
`openejb-jar.xml`:
[source,xml]
----
diff --git a/docs/ejb-refs.adoc b/docs/ejb-refs.adoc
index e17452d103..84dbc24cd2 100644
--- a/docs/ejb-refs.adoc
+++ b/docs/ejb-refs.adoc
@@ -11,7 +11,7 @@ Referencing a bean in another jar (with annotations)
When using annotations to reference a bean from another ejb in your ear
you have to supplement the `@EJB` reference with a small chunk of xml in
-the ejb-jar.xml of the referring bean.
+the `ejb-jar.xml` of the referring bean.
So in ejb app A colorsApp.jar you have this bean:
@@ -43,7 +43,7 @@ public class SquareBean implements SquareRemote {
----
To hook this reference up you need to override this ref and add more
-info in the ejb-jar.xml of shapesApp.jar as follows:
+info in the `ejb-jar.xml` of shapesApp.jar as follows:
[source,xml]
----
@@ -96,7 +96,7 @@ public class SquareBean implements SquareRemote {
----
Here's how you would hook this reference up, injection and all, with
-just xml. The following would be added to the ejb-jar.xml of
+just xml. The following would be added to the `ejb-jar.xml` of
shapesApp.jar:
[source,xml]
diff --git a/docs/ejbd-transport.adoc b/docs/ejbd-transport.adoc
index 0f1bfd8d2c..23ece1ae65 100644
--- a/docs/ejbd-transport.adoc
+++ b/docs/ejbd-transport.adoc
@@ -37,7 +37,7 @@ servlet.
Finally, you can move this servlet in your own webapp if you want to use
a provider url containing your webapp context. Simply copy and paste the
-servlet definition in your web.xml and set the url mapping to what you
+servlet definition in your `web.xml` and set the url mapping to what you
want (let's say /foo/*). Then use the provider url
http://<host>:<port>/<webapp context name>/foo
@@ -175,7 +175,7 @@ running on TomEE do not package the `ServerServlet`
themselves ensure
that the URL http://<host>:<port>/tomee/ejb is not accessible from
untrusted sources.
-If your applications package declare it in their own web.xml make sure
+If your applications package declare it in their own `web.xml` make sure
that the respective URL is not accessible from untrusted sources.
=== Revert to behavior of TomEE 1.7.2
diff --git a/docs/embedded-configuration.adoc b/docs/embedded-configuration.adoc
index beb683a2fe..d06db7197a 100644
--- a/docs/embedded-configuration.adoc
+++ b/docs/embedded-configuration.adoc
@@ -56,7 +56,7 @@ Everything in your logging.properties can be
configured/overridden via
properties. See link:configuring-logging-in-tests.html[Configuring
Logging in Tests].
-The properties of persistence units declared in a persistence.xml can be
+The properties of persistence units declared in a `persistence.xml` can be
configured/overridden via properties. See
link:configuring-persistenceunits-in-tests.html[Configuring
PersistenceUnits in Tests].
diff --git a/docs/functional-testing-with-openejb,-jetty-and-selenium.adoc
b/docs/functional-testing-with-openejb,-jetty-and-selenium.adoc
index 298ffaed02..dbbfcace6d 100644
--- a/docs/functional-testing-with-openejb,-jetty-and-selenium.adoc
+++ b/docs/functional-testing-with-openejb,-jetty-and-selenium.adoc
@@ -127,7 +127,7 @@ public class EmbeddedServer {
This class sets up an embedded instance of Jetty, running on port 9091.
You'll notice the setupJndi() method. This looks through the ejb-ref
-entries in web.xml (which we deserialize using the openejb-jee library),
+entries in `web.xml` (which we deserialize using the openejb-jee library),
and adds relevant LinkRefs to the JNDI tree, so you can look up beans
using the java:comp/env/bean format. I've added a main() method here for
convenience, so you can run this straight from an IDE, and record tests
diff --git a/docs/generating-ejb-3-annotations.adoc
b/docs/generating-ejb-3-annotations.adoc
index 9005d22b81..b1681b186a 100644
--- a/docs/generating-ejb-3-annotations.adoc
+++ b/docs/generating-ejb-3-annotations.adoc
@@ -7,7 +7,7 @@
= Generating EJB 3 annotations
The OpenEJB Eclipse plugin is able to provide some assistance in helping
-you migrate EJB 2.x projects to EJB 3.0, by analyzing your ejb-jar.xml
+you migrate EJB 2.x projects to EJB 3.0, by analyzing your `ejb-jar.xml`
file, and adding EJB annotations to your source code. This page will
show you how to use this functionality.
@@ -42,7 +42,7 @@ selected. Click 'Next'.
!http://www.jrg.me.uk/openejb/annotations_step_2.jpg!
-Select your ejb-jar.xml and (optionally) your openejb-jar.xml files.
+Select your `ejb-jar.xml` and (optionally) your `openejb-jar.xml` files.
Select or deselect the other options as appropriate, and select 'Next'.
Options:
diff --git a/docs/hibernate.adoc b/docs/hibernate.adoc
index 64b779b9df..dbe72fd5f3 100644
--- a/docs/hibernate.adoc
+++ b/docs/hibernate.adoc
@@ -8,7 +8,7 @@
For a unit called "movie-unit" using two datasources called
"movieDatabase" and "movieDatabaseUnmanaged" the following
-persistence.xml would work.
+`persistence.xml` would work.
[source,xml]
----
diff --git a/docs/jndi-names.adoc b/docs/jndi-names.adoc
index 064908dacb..701f216c39 100644
--- a/docs/jndi-names.adoc
+++ b/docs/jndi-names.adoc
@@ -66,7 +66,7 @@ The ejb-name as specified in xml or via the 'name' attribute
in
deploymentId
The unique system id for the ejb. Typically, the ejbName unless specified
-in the openejb-jar.xml or via changing the openejb.deploymentId.format
+in the `openejb-jar.xml` or via changing the `openejb.deploymentId.format`
interfaceType
@@ -85,7 +85,7 @@ This is the same as interfaceType.annotationName, but all in
lower case.
interfaceType.xmlName
-Following the ejb-jar.xml descriptor elements , , , , and : home (EJB 2
+Following the `ejb-jar.xml` descriptor elements , , , , and : home (EJB 2
EJBHome) local-home (EJB 2 EJBLocalHome) business-remote (EJB 3 Business
Remote) business-local (EJB 3 Business Local) service-endpoint (EJB
webservice endpoint)
@@ -150,7 +150,7 @@ InitialContext properties when embedded.
== Via properties in the openejb-jar.xml
It's possible to set the openejb.jndiname.format for an ejb-jar jar in a
-META-INF/openejb-jar.xml file as follows:
+`META-INF/openejb-jar.xml` file as follows:
[source,xml]
----
diff --git a/docs/jpa-usage.adoc b/docs/jpa-usage.adoc
index 89f9a6a12e..f195d9f1e5 100644
--- a/docs/jpa-usage.adoc
+++ b/docs/jpa-usage.adoc
@@ -9,7 +9,7 @@
== Critical: Always set jta-data-source and non-jta-data-source
Always set the value of jta-data-source and non-jta-data-source in your
-persistence.xml file. Regardless if targeting your EntityManager usage
+`persistence.xml` file. Regardless if targeting your EntityManager usage
for transaction-type="RESOURCE_LOCAL" or transaction-type="TRANSACTION",
it's very difficult to guarantee one or the other will be the only one
needed. Often times the JPA Provider itself will require both internally
diff --git a/docs/lookup-of-other-ejbs-example.adoc
b/docs/lookup-of-other-ejbs-example.adoc
index 0fe6460b39..043de21609 100644
--- a/docs/lookup-of-other-ejbs-example.adoc
+++ b/docs/lookup-of-other-ejbs-example.adoc
@@ -7,7 +7,7 @@
= Overview
This example shows how to configure JNDI to lookup other EJBs using
-either the _`@EJB_` annotation or the _ejb-jar.xml_ deployment descriptor.
+either the _`@EJB_` annotation or the `ejb-jar.xml` deployment descriptor.
There are a couple interesting aspects in this example intended to flush
out some of the more confusing, and perhaps frustrating, aspects of
@@ -82,7 +82,7 @@ _java:comp/env/myFriend_ name has been configured to point to
_BlueBean_
== Alternative to annotations
If there is a desire to not use annotations, the above annotation usage
-is equivalent to the following ejb-jar.xml
+is equivalent to the following `ejb-jar.xml`
\{snippet:url=openejb3/examples/lookup-of-ejbs-with-descriptor/src/main/resources/META-INF/ejb-jar.xml|lang=xml}
= Writing a unit test for the example
diff --git a/docs/new-in-openejb-3.0.adoc b/docs/new-in-openejb-3.0.adoc
index ab124033de..bc444846a3 100644
--- a/docs/new-in-openejb-3.0.adoc
+++ b/docs/new-in-openejb-3.0.adoc
@@ -72,7 +72,7 @@ public class MyBean {
== The META-INF/env-entries.properties
Along the lines of injection, one of the last remaining things in EJB 3
-that people need an ejb-jar.xml file for is to supply the value of
+that people need an `ejb-jar.xml` file for is to supply the value of
env-entries. Env Entries are the source of data for all user supplied
data injected into your bean; the afore mentioned String, Boolean,
Integer, etc. This is a very big burden as each env-entry is going to
@@ -83,10 +83,10 @@ all you want is to supply the value of a few `@Resource`
String fields in
you bean class.
To fix this, OpenEJB supports the idea of a
-META-INF/env-entries.properties file where we will look for the value of
+`META-INF/env-entries.properties` file where we will look for the value of
things that need injection that are not container controlled resources
(i.e. datasources and things of that nature). You can configure you ejbs
-via a properties file and skip the need for an ejb-jar.xml, and its 5
+via a properties file and skip the need for an `ejb-jar.xml` and its 5
lines per property madness.
[source,properties]
diff --git a/docs/openejb-eclipse-plugin.adoc b/docs/openejb-eclipse-plugin.adoc
index 4d0e080122..820f3f384a 100644
--- a/docs/openejb-eclipse-plugin.adoc
+++ b/docs/openejb-eclipse-plugin.adoc
@@ -12,7 +12,7 @@ The OpenEJB plugin for Eclipse provides the ability to run an
OpenEJB
standalone server and deploy projects directly from within the IDE,
using functionality provided by the Eclipse Web Tools Project (WTP).
Additionally, the plugin also provides the capability to read an
-ejb-jar.xml (and optionally an openejb-jar.xml) file and automatically
+`ejb-jar.xml` (and optionally an `openejb-jar.xml`) file and automatically
add the corresponding EJB 3 annotations to your code automatically.
link:installation.html[Installation]
diff --git a/docs/openjpa.adoc b/docs/openjpa.adoc
index ac76fe1fc7..8fce3bd892 100644
--- a/docs/openjpa.adoc
+++ b/docs/openjpa.adoc
@@ -127,6 +127,6 @@ You can either:
`TransactionAttributeType.NOT_REQUIRED` or
`TransactionAttributeType.NEVER` which will guarantee it will not be
invoked in a JTA transaction.
-. Change your persistence.xml so the persistence-unit uses
+. Change your `persistence.xml` so the persistence-unit uses
`transaction-type="TRANSACTION"` making it capable of participating in a
JTA transaction.
diff --git a/docs/properties-listing.adoc b/docs/properties-listing.adoc
index 77df3dc879..1df64db82d 100644
--- a/docs/properties-listing.adoc
+++ b/docs/properties-listing.adoc
@@ -665,7 +665,7 @@ openejb.web.xml.major
int
major version of web.xml. Can be useful to force tomcat to scan servlet
-3 annotatino when deploying with a servlet 2.x web.xml
+3 annotation when deploying with a servlet 2.x web.xml
tomee.jaxws.subcontext
diff --git a/docs/resource-injection.adoc b/docs/resource-injection.adoc
index b68e40330e..b28857a601 100644
--- a/docs/resource-injection.adoc
+++ b/docs/resource-injection.adoc
@@ -58,7 +58,7 @@ The _maxLineItem_ field in _PurchaseOrderBean_ class is
annotated with
the code the injection of a simple environment entry should take place.
The default value of 10 is assigned. You can modify the value of the
environment entries at deployment time using deployment descriptor
-(*ejb-jar.xml*).
+(`ejb-jar.xml`).
=== @Resource annotation of a field
diff --git a/docs/securing-a-web-service.adoc b/docs/securing-a-web-service.adoc
index 6c55fe0a9e..231529f4eb 100644
--- a/docs/securing-a-web-service.adoc
+++ b/docs/securing-a-web-service.adoc
@@ -66,7 +66,7 @@ provides a common and highly configurable way to configure
WS-Security
in association with the JAX-WS usage without vendor dependence.
Internally, OpenEJB integrates Apache WSS4J as the WS-Security
implementation. To use the integration, you will need to configure WSS4J
-using the _openejb-jar.xml_.
+using the `openejb-jar.xml`.
_Warning: the proposed WS-Security integration is only used at server
side. Currently, WS-Security client configuration is not managed by
@@ -81,8 +81,8 @@ messages (response).
= Configuration principles
-The configuration is made in the
-_openejb-jar.xml_. Each endpoint web service can provide a set of
+The configuration is made in the `openejb-jar.xml`.
+Each endpoint web service can provide a set of
properties to customize WS-Security behavior through the element. The
content of this element is consistent with the overall structure of
_openejb.xml_. The format for properties is the same as if you would use
@@ -104,7 +104,7 @@ For example : _wss4j.in.action = UsernameToken_
= Username Token (Password digest) example
-Excerpt from _openejb-jar.xml_.
+Excerpt from `openejb-jar.xml`.
[source,xml]
----
diff --git a/docs/singleton-beans.adoc b/docs/singleton-beans.adoc
index 9518188bc7..e059e846c8 100644
--- a/docs/singleton-beans.adoc
+++ b/docs/singleton-beans.adoc
@@ -211,7 +211,7 @@ needed.
= XML and Annotation Overriding
-Singletons can be declared in the ejb-jar.xml as follows:
+Singletons can be declared in the `ejb-jar.xml` as follows:
[source,xml]
----
diff --git a/docs/spring-and-openejb-3.0.adoc b/docs/spring-and-openejb-3.0.adoc
index be5b280028..47c8da44c6 100644
--- a/docs/spring-and-openejb-3.0.adoc
+++ b/docs/spring-and-openejb-3.0.adoc
@@ -83,7 +83,7 @@ EntityManagers or more that OpenEJB creates injected into
components
that Spring creates, here's one technique....
Let's say you have a persistence unit called "_OrangeUnit_" declared in
-a persistence.xml file. One way to get the related _EntityManager_
+a `persistence.xml` file. One way to get the related _EntityManager_
created by OpenEJB is to do as follows. Create an `@Stateless` bean with
an `@PersistenceContext` ref in it, then use a factory bean to look it up,
pull the EntityManager out and return it
diff --git a/docs/spring.adoc b/docs/spring.adoc
index b173a0d111..51b507e808 100644
--- a/docs/spring.adoc
+++ b/docs/spring.adoc
@@ -127,7 +127,7 @@ any error message(s) and the following information:
_JavaAgent_ - OpenEJB uses OpenJPA to provide JPA and CMP persistence,
and OpenJPA currently requires a JavaAgent to function properly in a
Java 1.5 environment. OpenJPA does not require a JavaAgent in Java 1.6.
-Use Hibernate as the provider in your persistence.xml files if you
+Use Hibernate as the provider in your `persistence.xml` files if you
wish to avoid this requirement.
_EntityManager_ - Having an OpenEJB created EntityManager or
diff --git a/docs/tip-concurrency.adoc b/docs/tip-concurrency.adoc
index 5a1273d342..6850bcc169 100644
--- a/docs/tip-concurrency.adoc
+++ b/docs/tip-concurrency.adoc
@@ -6,7 +6,7 @@
If for whatever reason you want to define the global default concurrency
-add this to your META-INF/ejb-jar.xml:
+add this to your `META-INF/ejb-jar.xml`:
[source,xml]
----
diff --git a/docs/tomcat-object-factory.adoc b/docs/tomcat-object-factory.adoc
index 5c1ec2c370..c70600fbf2 100644
--- a/docs/tomcat-object-factory.adoc
+++ b/docs/tomcat-object-factory.adoc
@@ -11,7 +11,7 @@ article "OpenEJB: EJB for Tomcat"] is no longer required._
As of OpenEJB 3.0 references from Servlets to EJBs happen automatically
with usage of the [`@EJB`
annotation](openejbx30:injection-of-other-ejbs-example.html) in the
-Servlet, Filter or Listener declared in the web.xml.
+Servlet, Filter or Listener declared in the `web.xml`.
See the openejbx30:tomcat.html[Tomcat Integration] page for the most
up-to-date details on using OpenEJB inside Tomcat.
diff --git a/docs/tomee-and-eclipse.adoc b/docs/tomee-and-eclipse.adoc
index 37a4cd985b..a4e14ae229 100644
--- a/docs/tomee-and-eclipse.adoc
+++ b/docs/tomee-and-eclipse.adoc
@@ -105,10 +105,10 @@ the changes to take effect.
=== JSP Hot Deployment
If jsp changes are not being hot deployed then this is because the jsp
-servlet is set to development=false in the web.xml file. To allow jsp
+servlet is set to `development=false` in the `web.xml` file. To allow jsp
hot deployment alter this value to true and restart Tomee.
-This is the relevant snippet of the web.xml file.
+This is the relevant snippet of the `web.xml` file.
[source,xml]
----
diff --git a/docs/tomee-and-security.adoc b/docs/tomee-and-security.adoc
index 43b659ad94..a39921e7eb 100644
--- a/docs/tomee-and-security.adoc
+++ b/docs/tomee-and-security.adoc
@@ -30,7 +30,7 @@ application] , all we would need to do is:
. Add some users to the tomcat-users.xml file +
. Add the necessary `@DefineRoles` and `@RolesAllowed` annotations on
MoviesImpl +
-. Add some security config to do HTTP Basic authentication to web.xml
+. Add some security config to do HTTP Basic authentication to `web.xml`
Webservice security is also looked after – username/password based
security (HTTP basic, or WS-Security) uses the same Tomcat security.
Certificate based security is also available.
