Share Utils class between OSGi
13 views
Skip to first unread message
Giacomo Petillo
Apr 14, 2021, 2:06:22 PM4/14/21
to dotCMS User Group
Hi all,
do you have an example of how to share a (utils) class between various OSGi plugins?
I suppose that I must create a fragment OSGi project in which I develop all the Util classes, it's right? If so, how can I add this class as an external dependency?
Thank you,
G.
Nathan Keiter
Apr 14, 2021, 2:33:28 PM4/14/21
to dotCMS User Group
There's not really a good way to share classes between OSGI plugins. I'd recommend against it.
You could either combine all of your functionality into a single plugin or have a copy of the util class package in each plugin (my approach.)
If the util classes are rather stable you could use a static plugin, but if you are constantly updating them that's not ideal.
Perhaps another option would be to expose your util functions as REST endpoints then send a localhost request to the endpoint, but that would only work with simple data-in/data-out functions. This would only work in limited cases.
Typically you want your OSGI plugins to work independently out of the box as a stand-alone program. Adding dependencies to other plugins will get messy.
Nathan I. Keiter | Lead Network Applications Programmer | I.D.E.A Council Member
Gettysburg College | Information Technology | DataSystems
Campus Box 2453 | 300 North Washington Street | Gettysburg, PA 17325
Phone: 717.337.6993
https://www.gettysburg.edu<https://www.gettysburg.edu/>
________________________________
From: dot...@googlegroups.com <dot...@googlegroups.com> on behalf of Giacomo Petillo <giacomo...@gmail.com>
Sent: Wednesday, April 14, 2021 2:06 PM
To: dotCMS User Group
Subject: [dotcms] Share Utils class between OSGi
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________
--
http://dotcms.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fdotcms.com&c=E,1,CUBhV2F5-BZ2xu_GkAIgjW1I1SstFQiPYbqo3eTB39LgD-CNd8-sdsBRCg3cfw7p2kFp0xbzAqSYv3WrwbhBX4EH67VabzXsatqZ9q4Yj8haZPJ4mQEDvBuCLA,,&typo=1> - Open Source Java Content Management
---
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com<mailto:dotcms+un...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/a7cdd015-a057-4bfe-9a0e-6bc26bd21381n%40googlegroups.com<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fgroups.google.com%2fd%2fmsgid%2fdotcms%2fa7cdd015-a057-4bfe-9a0e-6bc26bd21381n%2540googlegroups.com%3futm_medium%3demail%26utm_source%3dfooter&c=E,1,LWLoKKYQbOLconNHnOp8WDxbq3GCYIXcBmWuESziDd1eeDdCMCQ5h2c7e18TZTTWY7Z3oBx_qQWTUC8mD9wV-gp0t8_RQZYEHNBt7Pr7HP0d2kI8rIi6&typo=1>.
You could either combine all of your functionality into a single plugin or have a copy of the util class package in each plugin (my approach.)
If the util classes are rather stable you could use a static plugin, but if you are constantly updating them that's not ideal.
Perhaps another option would be to expose your util functions as REST endpoints then send a localhost request to the endpoint, but that would only work with simple data-in/data-out functions. This would only work in limited cases.
Typically you want your OSGI plugins to work independently out of the box as a stand-alone program. Adding dependencies to other plugins will get messy.
Nathan I. Keiter | Lead Network Applications Programmer | I.D.E.A Council Member
Gettysburg College | Information Technology | DataSystems
Campus Box 2453 | 300 North Washington Street | Gettysburg, PA 17325
Phone: 717.337.6993
https://www.gettysburg.edu<https://www.gettysburg.edu/>
________________________________
From: dot...@googlegroups.com <dot...@googlegroups.com> on behalf of Giacomo Petillo <giacomo...@gmail.com>
Sent: Wednesday, April 14, 2021 2:06 PM
To: dotCMS User Group
Subject: [dotcms] Share Utils class between OSGi
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________
http://dotcms.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fdotcms.com&c=E,1,CUBhV2F5-BZ2xu_GkAIgjW1I1SstFQiPYbqo3eTB39LgD-CNd8-sdsBRCg3cfw7p2kFp0xbzAqSYv3WrwbhBX4EH67VabzXsatqZ9q4Yj8haZPJ4mQEDvBuCLA,,&typo=1> - Open Source Java Content Management
---
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com<mailto:dotcms+un...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/a7cdd015-a057-4bfe-9a0e-6bc26bd21381n%40googlegroups.com<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fgroups.google.com%2fd%2fmsgid%2fdotcms%2fa7cdd015-a057-4bfe-9a0e-6bc26bd21381n%2540googlegroups.com%3futm_medium%3demail%26utm_source%3dfooter&c=E,1,LWLoKKYQbOLconNHnOp8WDxbq3GCYIXcBmWuESziDd1eeDdCMCQ5h2c7e18TZTTWY7Z3oBx_qQWTUC8mD9wV-gp0t8_RQZYEHNBt7Pr7HP0d2kI8rIi6&typo=1>.
Falzone, Chris
Apr 14, 2021, 3:28:55 PM4/14/21
to dot...@googlegroups.com
Yeah, as Nathan said it's not really best practice. OSGI Plugins are meant to stand on their own. But if you're set on going that route -- you don't need a fragment, you just need to expose (export) the package from the supplier and import it in the manifest of the consumer. Fragments only purpose is to do that sort of thing, so it is a better use case. For example if you have dependencies that are used in multiple OSGI Plugins you can expose them in a fragment and then have each one import the same versions of the dependency.
--
http://dotcms.com - Open Source Java Content Management
---
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/1618425204670.40677%40gettysburg.edu.
Giacomo Petillo
Apr 15, 2021, 4:47:27 AM4/15/21
to dotCMS User Group
Thanks Nathan and Chris,
with your answers I have a clear idea of the right way to develop an OSGi plugin: each plugin must be separate from the others.
In another scenario it's not the best, but in an OSGi environment it's the right choice.
Nathan Keiter
Apr 15, 2021, 9:45:50 AM4/15/21
to dot...@googlegroups.com
Giacomo,
Sounds like you got this! I just wanted to add one more comment.
One complicating factor (at least historically) is that you have no control of the start/deploy order of OSGI plugins.
* I have a 2 node cluster with 33 OSGI plugins on each node.
* They each have the same plugins, originally uploaded in the same order on both nodes.
* If a plugin is updated, I update it at the same time on both nodes.
However, when the dotCMS system restarts or the OSGI framework restarts, they DO NOT load the OSGI plugins in the same order.
Nathan I. Keiter | Lead Network Applications Programmer | I.D.E.A Council Member
Gettysburg College | Information Technology | DataSystems
Campus Box 2453 | 300 North Washington Street | Gettysburg, PA 17325
Phone: 717.337.6993
https://www.gettysburg.edu<https://www.gettysburg.edu/>
________________________________
From: dot...@googlegroups.com <dot...@googlegroups.com> on behalf of Giacomo Petillo <giacomo...@gmail.com>
Sent: Thursday, April 15, 2021 4:47 AM
To: dotCMS User Group
Subject: Re: [dotcms] Share Utils class between OSGi
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________
https://www.gettysburg.edu<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.gettysburg.edu&c=E,1,ev1iOSQrtWBAriCFD64x9e8ByauSf6N9g_qPniz7b8OlUNN5fZS-53LENPDCegy4t_3Nt3f1khJllDADH2oQ3w1JMMQND3-D34iUEyVikVZieHJ8J3o7sng,&typo=1><https://www.gettysburg.edu/<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.gettysburg.edu%2f&c=E,1,XnfTV9w8qM6gczH1WGbpb2mr6qdar1Bwv3PrqF4uVS89DdmG7b1rl0sb4hoG85OJN0OCxZ8uHakRZcOzYx9_CsRVVuba16fMDwD4PpaKdA,,&typo=1>>
--
http://dotcms.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fdotcms.com&c=E,1,15ngiwTj_S9TnZ2xM13X4n61dKBqOjUeukAi3exnjChzHkWh5VGah953LfNGjlvOX0eDx5S5pCUlo65LjQ1f1Cse32B7lSeL_7dV54oG2A,,&typo=1> - Open Source Java Content Management
---
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/1618425204670.40677%40gettysburg.edu<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fgroups.google.com%2fd%2fmsgid%2fdotcms%2f1618425204670.40677%2540gettysburg.edu&c=E,1,9K9IKeqBj28JZ9DE18mQ1Ddu4WZ3VcSbiKtXPUgABgybG802HmcKHSXN34oJJQ1WktFq6Xwkafuds9P-xGkpXwE4p3W5Fq_ypz5rsUhc3gxU&typo=1>.
--
Christopher Falzone
DevOps Engineer
A Q U E N T / VITAMIN T<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2faquent.com&c=E,1,dRp3b6Op_bzSK_LS1Y5swsFMFQhY_YrH6AhnXmSIq3Jv4IOhJNuxQUojaZxMkfnElIFpg-ikqpm0hBHVSi_scE2x9n2O5Xl7z0ItS6gecIVQtYLMNDKklAMlRJo,&typo=1>
--
http://dotcms.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fdotcms.com&c=E,1,r1hz3WfiI1ck4WyJjS8X3ERsaFp599dtAE63Qw8LZoa6Ij8Zl2lJ_soCqWIJcfdFe9bVh0pX6rpcA3-fs6Dc3j6IC4JWA5N-xU39zOuSmzhm_THQUdjWalJ0JA,,&typo=1> - Open Source Java Content Management
Sounds like you got this! I just wanted to add one more comment.
One complicating factor (at least historically) is that you have no control of the start/deploy order of OSGI plugins.
* I have a 2 node cluster with 33 OSGI plugins on each node.
* They each have the same plugins, originally uploaded in the same order on both nodes.
* If a plugin is updated, I update it at the same time on both nodes.
However, when the dotCMS system restarts or the OSGI framework restarts, they DO NOT load the OSGI plugins in the same order.
Nathan I. Keiter | Lead Network Applications Programmer | I.D.E.A Council Member
Gettysburg College | Information Technology | DataSystems
Campus Box 2453 | 300 North Washington Street | Gettysburg, PA 17325
Phone: 717.337.6993
https://www.gettysburg.edu<https://www.gettysburg.edu/>
________________________________
From: dot...@googlegroups.com <dot...@googlegroups.com> on behalf of Giacomo Petillo <giacomo...@gmail.com>
To: dotCMS User Group
Subject: Re: [dotcms] Share Utils class between OSGi
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________
Thanks Nathan and Chris,
with your answers I have a clear idea of the right way to develop an OSGi plugin: each plugin must be separate from the others.
In another scenario it's not the best, but in an OSGi environment it's the right choice.
Il giorno mercoledì 14 aprile 2021 alle 21:28:55 UTC+2 Chris Falzone ha scritto:
Yeah, as Nathan said it's not really best practice. OSGI Plugins are meant to stand on their own. But if you're set on going that route -- you don't need a fragment, you just need to expose (export) the package from the supplier and import it in the manifest of the consumer. Fragments only purpose is to do that sort of thing, so it is a better use case. For example if you have dependencies that are used in multiple OSGI Plugins you can expose them in a fragment and then have each one import the same versions of the dependency.
On Wed, Apr 14, 2021 at 2:33 PM 'Nathan Keiter' via dotCMS User Group <dot...@googlegroups.com> wrote:
There's not really a good way to share classes between OSGI plugins. I'd recommend against it.
You could either combine all of your functionality into a single plugin or have a copy of the util class package in each plugin (my approach.)
If the util classes are rather stable you could use a static plugin, but if you are constantly updating them that's not ideal.
Perhaps another option would be to expose your util functions as REST endpoints then send a localhost request to the endpoint, but that would only work with simple data-in/data-out functions. This would only work in limited cases.
Typically you want your OSGI plugins to work independently out of the box as a stand-alone program. Adding dependencies to other plugins will get messy.
Nathan I. Keiter | Lead Network Applications Programmer | I.D.E.A Council Member
Gettysburg College | Information Technology | DataSystems
Campus Box 2453 | 300 North Washington Street | Gettysburg, PA 17325
Phone: 717.337.6993<tel:(717)%20337-6993>
with your answers I have a clear idea of the right way to develop an OSGi plugin: each plugin must be separate from the others.
In another scenario it's not the best, but in an OSGi environment it's the right choice.
Il giorno mercoledì 14 aprile 2021 alle 21:28:55 UTC+2 Chris Falzone ha scritto:
Yeah, as Nathan said it's not really best practice. OSGI Plugins are meant to stand on their own. But if you're set on going that route -- you don't need a fragment, you just need to expose (export) the package from the supplier and import it in the manifest of the consumer. Fragments only purpose is to do that sort of thing, so it is a better use case. For example if you have dependencies that are used in multiple OSGI Plugins you can expose them in a fragment and then have each one import the same versions of the dependency.
On Wed, Apr 14, 2021 at 2:33 PM 'Nathan Keiter' via dotCMS User Group <dot...@googlegroups.com> wrote:
There's not really a good way to share classes between OSGI plugins. I'd recommend against it.
You could either combine all of your functionality into a single plugin or have a copy of the util class package in each plugin (my approach.)
If the util classes are rather stable you could use a static plugin, but if you are constantly updating them that's not ideal.
Perhaps another option would be to expose your util functions as REST endpoints then send a localhost request to the endpoint, but that would only work with simple data-in/data-out functions. This would only work in limited cases.
Typically you want your OSGI plugins to work independently out of the box as a stand-alone program. Adding dependencies to other plugins will get messy.
Nathan I. Keiter | Lead Network Applications Programmer | I.D.E.A Council Member
Gettysburg College | Information Technology | DataSystems
Campus Box 2453 | 300 North Washington Street | Gettysburg, PA 17325
https://www.gettysburg.edu<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.gettysburg.edu&c=E,1,ev1iOSQrtWBAriCFD64x9e8ByauSf6N9g_qPniz7b8OlUNN5fZS-53LENPDCegy4t_3Nt3f1khJllDADH2oQ3w1JMMQND3-D34iUEyVikVZieHJ8J3o7sng,&typo=1><https://www.gettysburg.edu/<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.gettysburg.edu%2f&c=E,1,XnfTV9w8qM6gczH1WGbpb2mr6qdar1Bwv3PrqF4uVS89DdmG7b1rl0sb4hoG85OJN0OCxZ8uHakRZcOzYx9_CsRVVuba16fMDwD4PpaKdA,,&typo=1>>
________________________________
From: dot...@googlegroups.com <dot...@googlegroups.com> on behalf of Giacomo Petillo <giacomo...@gmail.com>
Sent: Wednesday, April 14, 2021 2:06 PM
To: dotCMS User Group
Subject: [dotcms] Share Utils class between OSGi
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________
Hi all,
do you have an example of how to share a (utils) class between various OSGi plugins?
I suppose that I must create a fragment OSGi project in which I develop all the Util classes, it's right? If so, how can I add this class as an external dependency?
Thank you,
G.
--
http://dotcms.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fdotcms.com&c=E,1,Sq4hykB1YkouqnXB2TllG_4AOZCuX7RMFzsX_zLrZjj6D7-kE8hIysXCd0k6jCO7YcL1w-7I4QANNZpiyjZ6cXFuJ4w8YRTIgstpwhT0P5Z8JAbdUm3VRWE,&typo=1><https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fdotcms.com&c=E,1,CUBhV2F5-BZ2xu_GkAIgjW1I1SstFQiPYbqo3eTB39LgD-CNd8-sdsBRCg3cfw7p2kFp0xbzAqSYv3WrwbhBX4EH67VabzXsatqZ9q4Yj8haZPJ4mQEDvBuCLA,,&typo=1> - Open Source Java Content Management
From: dot...@googlegroups.com <dot...@googlegroups.com> on behalf of Giacomo Petillo <giacomo...@gmail.com>
Sent: Wednesday, April 14, 2021 2:06 PM
To: dotCMS User Group
Subject: [dotcms] Share Utils class between OSGi
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________
Hi all,
do you have an example of how to share a (utils) class between various OSGi plugins?
I suppose that I must create a fragment OSGi project in which I develop all the Util classes, it's right? If so, how can I add this class as an external dependency?
Thank you,
G.
--
---
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com<mailto:dotcms+un...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/a7cdd015-a057-4bfe-9a0e-6bc26bd21381n%40googlegroups.com<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fgroups.google.com%2fd%2fmsgid%2fdotcms%2fa7cdd015-a057-4bfe-9a0e-6bc26bd21381n%2540googlegroups.com&c=E,1,1jiwWnQ5IzDBFZFCiYudSfR14OOq5zWth0yfNko-eNwml-0xCoOpJXg2o_2alkFmanTqrkooAhZlvjusbYmyspIooKE1WdMmPalDgnpD-X7w3LT8Bw,,&typo=1><https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fgroups.google.com%2fd%2fmsgid%2fdotcms%2fa7cdd015-a057-4bfe-9a0e-6bc26bd21381n%2540googlegroups.com%3futm_medium%3demail%26utm_source%3dfooter&c=E,1,LWLoKKYQbOLconNHnOp8WDxbq3GCYIXcBmWuESziDd1eeDdCMCQ5h2c7e18TZTTWY7Z3oBx_qQWTUC8mD9wV-gp0t8_RQZYEHNBt7Pr7HP0d2kI8rIi6&typo=1>.
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com<mailto:dotcms+un...@googlegroups.com>.
--
http://dotcms.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fdotcms.com&c=E,1,15ngiwTj_S9TnZ2xM13X4n61dKBqOjUeukAi3exnjChzHkWh5VGah953LfNGjlvOX0eDx5S5pCUlo65LjQ1f1Cse32B7lSeL_7dV54oG2A,,&typo=1> - Open Source Java Content Management
---
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com.
--
Christopher Falzone
DevOps Engineer
--
http://dotcms.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fdotcms.com&c=E,1,r1hz3WfiI1ck4WyJjS8X3ERsaFp599dtAE63Qw8LZoa6Ij8Zl2lJ_soCqWIJcfdFe9bVh0pX6rpcA3-fs6Dc3j6IC4JWA5N-xU39zOuSmzhm_THQUdjWalJ0JA,,&typo=1> - Open Source Java Content Management
---
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com<mailto:dotcms+un...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/8aa00e28-f503-4681-b8f7-65ee7da6cab3n%40googlegroups.com<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fgroups.google.com%2fd%2fmsgid%2fdotcms%2f8aa00e28-f503-4681-b8f7-65ee7da6cab3n%2540googlegroups.com%3futm_medium%3demail%26utm_source%3dfooter&c=E,1,rNN16Ru5awG8_TuGXzntKKBDn4BJyV9B0AintnIW9iLzjU9CRVhwXmQ24rFQmmiXm_VHzIS2T8frP36BghgHvULFRGjk4A9IIcOde2Kr3T15kg5vZlzu&typo=1>.
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com<mailto:dotcms+un...@googlegroups.com>.
jonathan...@dotcms.com
Apr 15, 2021, 3:38:50 PM4/15/21
to dotCMS User Group
Hi Giacomo
I think you have two choices:
1) create an artifact and use them as a dependency and include as any other dependency in your plugin jar.
2) create a plugin that exposes an OSGI service into the OSGI context and get the reference, we used to have an example here
it shows how to expose a service from one plugin to another
Reply all
Reply to author
Forward
0 new messages