1. Home
  2. Development
  3. Alternative of shared/lib in OSGI and deploying conventional jars devstudio

Alternative of shared/lib in OSGI and deploying conventional jars devstudio

adeeb khalid, modified 6 Years ago.
Alternative of shared/lib in OSGI and deploying conventional jars devstudio
New Member Posts: 9 Join Date: 7/9/19 Recent Posts
Hi fellow Liferay developers,

I hope you guys may be doing well, I have 2 questions regarding Liferay DevStudio,OSGI and Tomcat:
- Alternative of tomcat shared/lib in OSGI, I am looking for alternative of shared/lib of tomcat in OSGI so that any run time dependencies should be added once in some sort of OSGI shared/lib if any? to avoid ClassNotFound/ClassDefNotFound exceptions when deploying portlets having such dependencies(As OSGI resolves dependencies while deployment).
- Deploying conventional Wars and Jars through Liferay Developer studio so no server restart is required, As any jars/wars deployed in DevStudio are handled & deployed by OSGI(not in conventional way), I am looking for a way to deploy these jars/wars to be directly deployed on Server e.g. Tomcat, Suggest any filter or any other way to skip these jars to be handled directly by Server.

Best Regards.
thumbnail
Olaf Kock, modified 6 Years ago.
RE: Alternative of shared/lib in OSGI and deploying conventional jars devst
Liferay Legend Posts: 6441 Join Date: 9/23/08 Recent Posts
adeeb khalid:

- Alternative of tomcat shared/lib in OSGI, I am looking for alternative of shared/lib of tomcat in OSGI so that any run time dependencies should be added once in some sort of OSGI shared/lib if any? to avoid ClassNotFound/ClassDefNotFound exceptions when deploying portlets having such dependencies(As OSGI resolves dependencies while deployment).
You just deploy them to the OSGi runtime. There's no special "shared" lib: If one jar is required to meet some dependency,  it'll be utilized. All jars in the runtime are inherently "shared"

- Deploying conventional Wars and Jars through Liferay Developer studio so no server restart is required, As any jars/wars deployed in DevStudio are handled & deployed by OSGI(not in conventional way), I am looking for a way to deploy these jars/wars to be directly deployed on Server e.g. Tomcat, Suggest any filter or any other way to skip these jars to be handled directly by Server.
Liferay is a webapplication. You can deploy any other web application to the application server or servlet container that you use. They'll just not be integrated with Liferay if you do so - but you've only asked how to install them to your server. For tomcat: Place them in tomcat's webapps directory.
adeeb khalid, modified 6 Years ago.
RE: Alternative of shared/lib in OSGI and deploying conventional jars devst
New Member Posts: 9 Join Date: 7/9/19 Recent Posts
You just deploy them to the OSGi runtime. There's no special "shared" lib: If one jar is required to meet some dependency,  it'll be utilized. All jars in the runtime are inherently "shared"


Thanks for clarification but Do these jars will be available to applications(Other than Liferay) deployed on server or there will be need of ServiceLocator or something like that to access these jars?

Liferay is a webapplication. You can deploy any other web application to the application server or servlet container that you use. They'll just not be integrated with Liferay if you do so - but you've only asked how to install them to your server. For tomcat: Place them in tomcat's webapps directory.


Basically in Liferay 6.2 we were used to deploy web applications(other than Liferay) through developer studio and those applications were deployed directly into webapps(sort of hot deploy), currently OSGI handles these wars when deployed via developer studio and tries to populate in Root and these webapplications donot get direclty deployed in webapps. I know we can deploy other wars by script or manually in webapps but i am looking to deploy directly from DevStudio(drag&drop) for debug and quick deployment purposes. Any suggestions regarding this?
thumbnail
Christoph Rabel, modified 6 Years ago.
RE: Alternative of shared/lib in OSGI and deploying conventional jars devst
Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
You might want to look at this free Liferay course:
https://university.liferay.com/osgi-basics
It is really helpful to understand, what OSGI does for you. Once you understand it you will realize, that things got better (with a few exceptions).
About the quick deploy: There was a project (plugin?) that allowed people to use exploded jars for development. But I never used it and can't find it at the moment. I personally never found this as useful as in 6.2. In 6.2 deployment was far slower than in 7.0+.  We also don't develop real portlets anymore, only rest + js frontend.
Long story short: There is a way to do have exploded jars for hot deployment, maybe somebody here remembers how to do it.
adeeb khalid, modified 6 Years ago.
RE: Alternative of shared/lib in OSGI and deploying conventional jars devst
New Member Posts: 9 Join Date: 7/9/19 Recent Posts
Thanks for the OSGI basic course link pal, i had gone through it. But the questions i am asking are OUT of scope for this course it describes just basic concept of OSGI e.g. jar hell, resolving dependencies, OSGI handling lifecycle etc. Good to know you have moved to "rest + js" but its a long story we still have jars, portlets and jsp's to be migrated in short span.
But i am still interrogating for views regarding above mentioned things?
thumbnail
Christoph Rabel, modified 6 Years ago.
RE: Alternative of shared/lib in OSGI and deploying conventional jars devst
Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
Well, your questions were quite basic. Simply said: Each OSGI module has Exports. Anything thats exported can be used in other OSGI modules. Components can also be requested using @Reference in a dependecy injection way.
Deployment: I found it. It was called liferay-osgi-watch. I never used it but it was supposed to speedup deploy times. I am not sure if it still works, but you could give it a try:
https://github.com/liferay/liferay-osgi-watch
adeeb khalid, modified 6 Years ago.
RE: Alternative of shared/lib in OSGI and deploying conventional jars devst
New Member Posts: 9 Join Date: 7/9/19 Recent Posts
Thanks for guidance but here I am talking about conventional jars, which are not developed on OSGI service model. We have not migrated these jars for OSGI and want to deploy these on OSGI, so my questions were about these jars.
thumbnail
Christoph Rabel, modified 6 Years ago.
RE: Alternative of shared/lib in OSGI and deploying conventional jars devst
Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
You need to include them in your jars. e.g. using the compileInclude directive. With that your jar files are packaged into the osgi module you are creating.
adeeb khalid, modified 6 Years ago.
RE: Alternative of shared/lib in OSGI and deploying conventional jars devst
New Member Posts: 9 Join Date: 7/9/19 Recent Posts
<p>That&#39;s one way of doing this and it would be last approach to include jars with in jars e.g. portlets. But i was wondering if there will be a way for shared jars if multiple jars are using same jar and redundancy can be avoided.<br />
And about deploying conventional wars in DevStudio in parallel with Liferay Webapps i think i have to provide a metadata/bnd file for OSGI to convert war into wab. I am looking in to it &amp; will get back if successfull. Please share if any one have prior experience of converting these wars into wab.</p>
thumbnail
Christoph Rabel, modified 6 Years ago.
RE: Alternative of shared/lib in OSGI and deploying conventional jars devst (Answer)
Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
Well, if you don't want to "migrate" them, you need to include them.
Of course, a better approach is to to "osgify" them. We have several library modules which just export some packages. e.g. data transfer objects which are needed by multiple modules. And some helper code.
In general you just need to create a module, add the source code of your modules, add a build.gradle and a bnd.bnd file with an Export-Package directive and you are done.
There's also an eclipse wizard that allows you to create an osgi module out of jar files.
thumbnail
Olaf Kock, modified 6 Years ago.
RE: Alternative of shared/lib in OSGI and deploying conventional jars devst
Liferay Legend Posts: 6441 Join Date: 9/23/08 Recent Posts
adeeb khalid:

I know we can deploy other wars by script or manually in webapps but i am looking to deploy directly from DevStudio(drag&amp;drop) for debug and quick deployment purposes.
Yes: You just continue to drag your plugins onto the server in DevStudio's server view, just like before. It gets hot deployed to Liferay.
Or did you want to develop Liferay-unrelated webapplications to tomcat, as well as Liferay-related ones - both in parallel? I've never tried that.
adeeb khalid, modified 6 Years ago.
RE: Alternative of shared/lib in OSGI and deploying conventional jars devst
New Member Posts: 9 Join Date: 7/9/19 Recent Posts
Yes in parallel, i have tried that it comes with bundles of exceptions with nothing running out of these wars/webapps, as they don't contain any metadata to be deployed by OSGI.
thumbnail
David H Nebinger, modified 6 Years ago.
RE: Alternative of shared/lib in OSGI and deploying conventional jars devst (Answer)
Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
For classes to be both global for tomcat (tomcat's lib or lib/ext) and available in OSGi, you have to deploy the jar into tomcat's lib (or lib/ext) folder.

Then you need to add the packages in the module.framework.properties.org.osgi.framework.bootdelegation property in portal-ext.properties (retaining the current list).

Note, however, that this will limit your ability to use different versions of the code in the OSGi container; a global class will always load from global, preventing a local class load.

This is the reason that this kind of thing is not documented, it does not lead to healthy outcomes for your OSGi container.
Olaf Kock, modified 5 Years ago.
RE: Alternative of shared/lib in OSGI and deploying conventional jars devst
New Member Posts: 9 Join Date: 9/18/19 Recent Posts
Thank you David for providing this workaround. Would you please explain more the downside of it, i didn't really get how preventing a local class to load?
​​​​​​​
thumbnail
David H Nebinger, modified 5 Years ago.
RE: Alternative of shared/lib in OSGI and deploying conventional jars devst
Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
Class loader use a top down approach to find classes to load. Global classes are at the top, so they load before a local class. So a version you might need to use can’t be used because global comes first. Tomcat May not allow you to change the file while it is running so this can be a deployment issue. For those app servers that do support the change while running, you can’t be 100% Sure it is applied correctly without a restart, so it is another deployment issue. 


don’t over think class loading. Don’t think you have to make something global to save memory or something. You likely won’t ever have evidence that this is a problem in your environment, it is typically just a guess that it would be a problem sometime in the future. Just avoid the global, avoid trying to solve problems you don’t have. Do things the standard way and, if you do have a problem, then you solve it. 
Michael El Khoury, modified 5 Years ago.
RE: Alternative of shared/lib in OSGI and deploying conventional jars devst
New Member Posts: 9 Join Date: 9/18/19 Recent Posts
Thank you, i perfectly got what you mean.
I'm currently using the lib/ext to deploy a singleton which contains a watcher pattern that watches when changes is done in a folder; 
when a property file is modified in this directory, the singleton will reload its static map containing the keys read from this property file.

I need to access the singleton in the freemarker template of the theme (which made me implement a "template context contributor") which i liked very much.
And i also need to be able to access this singleton from migrated war-mvc-portlets.
Now if i convert this singleton to an osgi bundle i'll have no problem using it the "template context contributor" since it's also a bundle.
But what i'm not sure of is the possibility to access this osgi bundle from a war-mvc-protlet , without it beeing bundled inside the war when transformed to an osgi bundle, because i'll lose the "singleton" concept thing (it won't be shared because i'll have another instance of it in the war portlet).
Thank you in advance, i hope i'm not over-asking questions emoticon
thumbnail
David H Nebinger, modified 5 Years ago.
RE: Alternative of shared/lib in OSGI and deploying conventional jars devst
Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
That's a shame. Instead, you could have included an "include-and-override=/path/to/my/file.properties" line to portal-ext.properties and it would have taken care of all of that for you...

Then you could have just invoked Liferay's PropsUtil to get the values when you need them.  It is visible within the template handlers already (eliminating the need for a custom template context contributor), is accessible from new OSGi modules as well as legacy portlet wars using the PropsUtil static class, ...

But now you have a custom thing that you have to maintain entirely, deploy it outside of the normal scope, maybe even require a restart to ensure that no one is holding onto the singleton instance, ...

Another alternative, if you leveraged .cfg or .config files per the Liferay way, OSGi would automatically watch the files for changes. OSGi would invoke your @Modified method when the config changed and you could always use ConfigAdmin to do a lookup for a configuration interface and it would always return the current value (not a cached value).

I guess the moral is, Liferay has a ton of functionality built in to handle more stuff than you can believe. Often it is not really necessary to roll your own solution for something, sometimes it's just a matter of asking "How can I ..." here so we can offer up suggestions that would be easier to maintain and might even eliminate a need for custom coding.
Michael El Khoury, modified 5 Years ago.
RE: Alternative of shared/lib in OSGI and deploying conventional jars devst
New Member Posts: 9 Join Date: 9/18/19 Recent Posts
Thank you Dave, i will look more into your suggestion. i can always change my solution, it's not even committed yet.
The problem is we are not very familiar yet with the OSGi concepts . next time i will gladly be asking the "how can i..." questions before!
Thanks again emoticon
thumbnail
David H Nebinger, modified 5 Years ago.
RE: Alternative of shared/lib in OSGI and deploying conventional jars devst
Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
That's the thing though, if you are this early it is worth refactoring into a standard model. 
adeeb khalid, modified 6 Years ago.
RE: Alternative of shared/lib in OSGI and deploying conventional jars devst (Answer)
New Member Posts: 9 Join Date: 7/9/19 Recent Posts
Thanks a lot every one for sharing kind information, a lot of things have been sorted regarding 2 questions asked and are as follows:
1. To use conventional jars in OSGI :
Of course, a better approach is to to "osgify" them. We have several library modules which just export some packages. e.g. data transfer objects which are needed by multiple modules. And some helper code.
In general you just need to create a module, add the source code of your modules, add a build.gradle and a bnd.bnd file with an Export-Package directive and you are done.
There's also an eclipse wizard that allows you to create an osgi module out of jar files.

For classes to be both global for tomcat (tomcat's lib or lib/ext) and available in OSGi, you have to deploy the jar into tomcat's lib (or lib/ext) folder.

Then you need to add the packages in the module.framework.properties.org.osgi.framework.bootdelegation property in portal-ext.properties (retaining the current list).

Note, however, that this will limit your ability to use different versions of the code in the OSGi container; a global class will always load from global, preventing a local class load

2. To deploy wars in to DevStudio by drag and drop in server view or in OSGI deploy folder:
And about deploying conventional wars in DevStudio in parallel with Liferay Webapps i think i have to provide a metadata/bnd file for OSGI to convert war into wab. I am looking in to it &amp; will get back if successfull. Please share if any one have prior experience of converting these wars into wab.