diff --git a/documentation/implementing-authprovider-guide.html b/documentation/implementing-authprovider-guide.html index 9e3ffbfa39..0617f67282 100644 --- a/documentation/implementing-authprovider-guide.html +++ b/documentation/implementing-authprovider-guide.html @@ -87,8 +87,8 @@
provider.auth.className
to be the full name of your class, e.g.
@@ -140,6 +140,26 @@ + Yes, and no. Your code will run using the same classpath as Openfire. Openfire's dependencies are already on + that classpath. If your code uses the same dependencies, you do not need to include them again. You can add + other dependencies, either by packaging them in your jar file, or by placing them in the openfire lib folder. +
++ Beware of conflicting dependencies! Sometimes, packaging dependencies in an all-containing jar, and renaming + the packages of those dependencies (shade them), can be helpful. +
+ ++ It is not recommended to use a plugin for packaging and deploying your provider. For one, plugins use a + dedicated class path. For another, the load order of plugins could lead to hairy scenarios, and finally: + plugins can be unloaded at runtime. This all could lead to a running Openfire service for which you + cannot guarantee that your provider is loaded at all times. For these reasons, we recommend creating a jar + file instead of an Openfire plugin, and placing that jar file in Openfire's lib directory! +
+
Openfire's own authentication mechanism makes use of the AuthProvider
API! If you want to get
diff --git a/documentation/implementing-groupprovider-guide.html b/documentation/implementing-groupprovider-guide.html
index 301b4282f1..ab0b748bc8 100644
--- a/documentation/implementing-groupprovider-guide.html
+++ b/documentation/implementing-groupprovider-guide.html
@@ -93,8 +93,8 @@
provider.group.className
to be the full name of your class, e.g.
@@ -147,6 +147,26 @@ + Yes, and no. Your code will run using the same classpath as Openfire. Openfire's dependencies are already on + that classpath. If your code uses the same dependencies, you do not need to include them again. You can add + other dependencies, either by packaging them in your jar file, or by placing them in the openfire lib folder. +
++ Beware of conflicting dependencies! Sometimes, packaging dependencies in an all-containing jar, and renaming + the packages of those dependencies (shade them), can be helpful. +
+ ++ It is not recommended to use a plugin for packaging and deploying your provider. For one, plugins use a + dedicated class path. For another, the load order of plugins could lead to hairy scenarios, and finally: + plugins can be unloaded at runtime. This all could lead to a running Openfire service for which you + cannot guarantee that your provider is loaded at all times. For these reasons, we recommend creating a jar + file instead of an Openfire plugin, and placing that jar file in Openfire's lib directory! +
+
Openfire's own group functionality makes use of the GroupProvider
API! If you want to get
diff --git a/documentation/implementing-userprovider-guide.html b/documentation/implementing-userprovider-guide.html
index f10546f59e..acb5db8a2d 100644
--- a/documentation/implementing-userprovider-guide.html
+++ b/documentation/implementing-userprovider-guide.html
@@ -86,8 +86,8 @@
provider.user.className
to be the full name of your class, e.g.
@@ -139,6 +139,26 @@ + Yes, and no. Your code will run using the same classpath as Openfire. Openfire's dependencies are already on + that classpath. If your code uses the same dependencies, you do not need to include them again. You can add + other dependencies, either by packaging them in your jar file, or by placing them in the openfire lib folder. +
++ Beware of conflicting dependencies! Sometimes, packaging dependencies in an all-containing jar, and renaming + the packages of those dependencies (shade them), can be helpful. +
+ ++ It is not recommended to use a plugin for packaging and deploying your provider. For one, plugins use a + dedicated class path. For another, the load order of plugins could lead to hairy scenarios, and finally: + plugins can be unloaded at runtime. This all could lead to a running Openfire service for which you + cannot guarantee that your provider is loaded at all times. For these reasons, we recommend creating a jar + file instead of an Openfire plugin, and placing that jar file in Openfire's lib directory! +
+
Openfire's own user functionality makes use of the UserProvider
API! If you want to get
diff --git a/documentation/pluggable-roster-support-guide.html b/documentation/pluggable-roster-support-guide.html
index 7071e9d51e..53f8e0bd3c 100644
--- a/documentation/pluggable-roster-support-guide.html
+++ b/documentation/pluggable-roster-support-guide.html
@@ -85,8 +85,8 @@
+ Yes, and no. Your code will run using the same classpath as Openfire. Openfire's dependencies are already on + that classpath. If your code uses the same dependencies, you do not need to include them again. You can add + other dependencies, either by packaging them in your jar file, or by placing them in the openfire lib folder. +
++ Beware of conflicting dependencies! Sometimes, packaging dependencies in an all-containing jar, and renaming + the packages of those dependencies (shade them), can be helpful. +
+ ++ It is not recommended to use a plugin for packaging and deploying your provider. For one, plugins use a + dedicated class path. For another, the load order of plugins could lead to hairy scenarios, and finally: + plugins can be unloaded at runtime. This all could lead to a running Openfire service for which you + cannot guarantee that your provider is loaded at all times. For these reasons, we recommend creating a jar + file instead of an Openfire plugin, and placing that jar file in Openfire's lib directory! +
+It completely depends on your implementation. As with any Openfire customisation or plugin, badly written