From 56f0826d8e2fad9e078c973a5a6a3367d09abe19 Mon Sep 17 00:00:00 2001
From: Guus der Kinderen The AuthProvider extension point
provider.auth.className
to be the full name of your class, e.g.
@@ -140,6 +140,26 @@ How do I ensure my custom class is visible on the Openfire classpath?
available at startup.
+ 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 scenario's, 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..a2a0bde251 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 scenario's, 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..2e9328a8c9 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 scenario's, 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..fca459a4af 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 scenario's, 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
From 9aa2318f8c1722eedda9223d2dd7a4c924e1f5b7 Mon Sep 17 00:00:00 2001
From: Dan Caseley
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 scenario's, and finally:
+ 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!
From 28afd189aa039bf58eb6adea49a63949e2c28cfc Mon Sep 17 00:00:00 2001
From: Dan Caseley
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 scenario's, and finally:
+ 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!
From 172408acf8de148697108b322e0e045d1dfa791e Mon Sep 17 00:00:00 2001
From: Dan Caseley
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 scenario's, and finally:
+ 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!
From c827d2dd58f5baf358ce83b1145cb009e097228e Mon Sep 17 00:00:00 2001
From: Dan Caseley
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 scenario's, and finally:
+ 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!
Should I include all the dependencies that my code needs?
Isn't it easier to deploy my code as an Openfire plugin?
Should I include all the dependencies that my code needs?
Isn't it easier to deploy my code as an Openfire plugin?
Should I include all the dependencies that my code needs?
Isn't it easier to deploy my code as an Openfire plugin?
Should I include all the dependencies that my code needs?
Isn't it easier to deploy my code as an Openfire plugin?