Bug 52381 - Please add OSGi metadata
Summary: Please add OSGi metadata
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Packaging (show other bugs)
Version: trunk
Hardware: PC Linux
: P2 enhancement with 2 votes (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-22 12:28 UTC by Alexander Kurtakov
Modified: 2018-05-29 14:34 UTC (History)
3 users (show)



Attachments
Attempt to add OSGi metadata (9.98 KB, patch)
2017-12-20 21:59 UTC, Coty Sutherland
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Kurtakov 2011-12-22 12:28:15 UTC
As a downstream we(Fedora) modify a number of the Tomcat jars to add OSGi metadata in them. You can see them here http://pkgs.fedoraproject.org/gitweb/?p=tomcat.git;a=tree . But the process is really error prone and somethimes versions go out of sync. It would be really cool if this metadata is properly generated by the buildsystem.
Comment 1 Alexander Kurtakov 2011-12-22 12:40:36 UTC
The manifests used aren't good enough for inclusion but I'll try to come with something better after vacation.
Comment 2 Mark Thomas 2011-12-23 21:27:07 UTC
Not knowing much about OSGI, if you could provide suitable manifests that would be great. Once we have them, plugging them into the build is relatively simple.
Comment 3 Mark Thomas 2011-12-29 20:11:43 UTC
Marking as an enhancement.
Comment 4 pan4o 2012-01-05 12:45:51 UTC
This is a very important issue for us too, because of our Apache Karaf environment. See bugs 52318 and 52429
Comment 5 Violeta Georgieva 2012-01-12 21:49:43 UTC
Hello,

In Eclipse Virgo we add OSGi metadata using Bundlor. The process is pretty straightforward and we have projects that do that stuff. Unfortunately we do not add OSGi metadata for every Apache Tomcat release but only for those that we include in Eclipse Virgo.

The artifacts are available through EBR. Here they are:

http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.catalina&version=7.0.23&searchType=bundlesByName&searchQuery=catalina

http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.catalina.ha&version=7.0.23&searchType=bundlesByName&searchQuery=catalina

http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.catalina.tribes&version=7.0.23&searchType=bundlesByName&searchQuery=catalina

http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.coyote&version=7.0.23&searchType=bundlesByName&searchQuery=coyote

http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.jasper&version=7.0.23&searchType=bundlesByName&searchQuery=jasper

http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.el&version=7.0.23&searchType=bundlesBySymbolicName&searchQuery=org.apache.el

http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.juli.extras&version=7.0.23&searchType=bundlesBySymbolicName&searchQuery=juli

http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.tomcat.api&version=7.0.23&searchType=bundlesBySymbolicName&searchQuery=org.apache.tomcat

http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.tomcat.util&version=7.0.23&searchType=bundlesBySymbolicName&searchQuery=org.apache.tomcat

Best Regards
Violeta Georgieva
Comment 6 Glyn Normington 2012-02-17 11:17:56 UTC
If OSGi metadata is added, I suggest also adding a basic test to Tomcat's build to check that the Tomcat bundle resolve. (I created a similar test for Spring and I recommend the approach of using Pax Exam - see https://jira.springsource.org/browse/SPR-8791).
Comment 7 Alexander Kurtakov 2012-02-17 11:21:59 UTC
In order to avoid cyclic dependencies and yes servlet.jar is used in too many places so having dependencies to build its osgi metadata will be a big PITA I think that the simplest approach for building would be best - no bundlor, no pam-exam and etc.The manifest is just few key/value pairs in the manifest after all. This doesn't mean that tests/verification/etc. targets should not be added but the buildsystem itself should work without them.
Comment 8 Mark Thomas 2012-03-20 22:36:51 UTC
As far as I am aware, there is very little OSGI expertise amongst the Tomcat devs. What is really required for this enhancement is either:
- a patch that generates the necessary meta data as part of the build script; or
- a simple (no long words please) explanation of exactly what needs to be included in the meta data so someone with no OSGI understanding can generate it.
Comment 9 pan4o 2012-03-21 06:18:23 UTC
Very important for each bundle are the imports and exports sections in the MANIFEST file. We do this so:

<plugin>
	<groupId>org.apache.felix</groupId>
	<artifactId>maven-bundle-plugin</artifactId>
	<version>2.3.4</version>
	<extensions>true</extensions>
	<configuration>
        <instructions>
		<Require-Bundle />
		<Export-Package>our.package;version="${pom.version}"
                </Export-Package>
		<Import-Package>!our.package,org.springframework.aop;version="${spring.version}",org.springframework.aop.framework;version="${spring.version}",org.aopalliance.aop, *               </Import-Package>
		<Embed-Dependency>*;artifactId=postgresql,*;artifactId=tomcat-jdbc</Embed-Dependency>
	</instructions>
	</configuration>
</plugin>

Embed-Dependency because postgresql and tomcat-jdbs are not correct bundles.
Comment 10 pan4o 2012-03-22 12:51:21 UTC
if you need a more detailed POM ... i will submit a complete one :)
Comment 11 Mark Thomas 2012-03-22 12:54:10 UTC
The POM is no use since Tomcat is not built with Maven. What is required is details of what needs to go into the manifests.
Comment 12 pan4o 2012-03-22 13:18:20 UTC
All dependencies (imports) you need in a project, should be in Import-Package:
All packages you want to expose (make them public), should be in Export-Package: 

In the OSGI way you can expose throgh the Export-Package only that what you want to be public. In the sample MANIFEST we are exposing only our interfaces without exposing the implementation. Sooo no external package running in Karaf can access the implementation.


Sample MANIFEST:

Manifest-Version: 1.0
Export-Package: our.package;version="0.0.1.SNAPSHOT"
Bundle-ClassPath: .,postgresql-9.0-801.jdbc4.jar,tomcat-jdbc-7.0.22.jar
Built-By: hudson
Tool: Bnd-1.15.0
Bundle-Name: our.package
Created-By: Apache Maven Bundle Plugin
Build-Jdk: 1.6.0_21
Bundle-Version: 0.0.1.SNAPSHOT
Bnd-LastModified: 1330958118424
Bundle-ManifestVersion: 2
Embed-Dependency: *;artifactId=postgresql,*;artifactId=tomcat-jdbc
Import-Package: org.springframework.jdbc.core.namedparam;version="[3
 .0,4)",org.springframework.jdbc.core.simple;version="[3.0,4)",org.spr
 ingframework.jdbc.datasource;version="[3.0,4)",org.springframework.tr
 ansaction.annotation;version="[3.0,4)",org.w3c.dom,org.xml.sax
Bundle-SymbolicName: our.package
Comment 13 Coty Sutherland 2017-12-20 21:59:05 UTC
Created attachment 35625 [details]
Attempt to add OSGi metadata

Back on 2011-09-06 Roland Grunberg added the OSGi manifests that are used in the Fedora-generated Tomcat JARs today (see http://pkgs.fedoraproject.org/cgit/rpms/tomcat.git/tree/ for more details). I see now that those are outdated (old spec versions and such) so I'll update them at some point. Using those as an example of what's required, I updated the templates found in res/META-INF/*.manifest to add the OSGi metadata and added a few new manifests that include OSGi metadata in the manner discussed in previous comments (not using bundlor, or anything special). Hopefully this is correct...

Disclaimer: I don't know much about OSGi, have no way to test this, and it seems that nobody is using the Fedora ones because there is incorrect information in them, so they may be wrong.
Comment 14 Violeta Georgieva 2017-12-20 22:50:03 UTC
(In reply to Coty Sutherland from comment #13)
> Created attachment 35625 [details]
> Attempt to add OSGi metadata
> 
> Back on 2011-09-06 Roland Grunberg added the OSGi manifests that are used in
> the Fedora-generated Tomcat JARs today (see
> http://pkgs.fedoraproject.org/cgit/rpms/tomcat.git/tree/ for more details).
> I see now that those are outdated (old spec versions and such) so I'll
> update them at some point. Using those as an example of what's required, I
> updated the templates found in res/META-INF/*.manifest to add the OSGi
> metadata and added a few new manifests that include OSGi metadata in the
> manner discussed in previous comments (not using bundlor, or anything
> special). Hopefully this is correct...
> 
> Disclaimer: I don't know much about OSGi, have no way to test this, and it
> seems that nobody is using the Fedora ones because there is incorrect
> information in them, so they may be wrong.

Hi Coty,

I'm can help with OSGi (I'm committer in Gemini Web - OSGi web container reference implementation). Tomcat version 8.5.16 is the latest version that I have with OSGi meta data.
However every project has its own understanding what should be included in the OSGi meta data.

Regards,
Violeta
Comment 15 Coty Sutherland 2018-01-24 20:46:41 UTC
Any thoughts on the patch? It's a rough draft and I should replace all the hard coded spec version info with dynamic stuff, but as far as using these manifests as a template to fill in other info, does that look OK to anyone/everyone? I don't see any other easy alternative to generate this info except maybe Apache Ivy, which has an experimental OSGi bundle thingy.
Comment 16 Mark Thomas 2018-05-25 07:34:03 UTC
I have a few comments but keep in mind my minimal OSGI knowledge:

- I see placeholders %bundleProvider, %bundleName etc. nut nothing to populate them

- The execution environments look wrong given the java version they are compiled for

- The imports for jasper.jar look to be too wide. org.apache.commons.el, for example, is an old UEL implementation that Tomcat shouldn't (and doesn't as far as I know) depend on

- version numbers need updating for Tomcat 9 (Servlet 4.0)

I also compared the the patch to the manifests provided in the latest Eclipse Virgo release. There are a lot of differences. I'm not sure how significant they are.
Comment 17 Mark Thomas 2018-05-25 09:37:53 UTC
I'm making some progress integrating bnd into the trunk build via the Ant plug-in. I've got it to the point where JARs with OSGI manifests are created. The next steps are:

a) add property files for each JAR so we can tailor each OSGI manifest appropriately
b) get the manifests reviewed
c) modify the build process so JARs are created with the OSGI manifest

I should be in a position to commit something later today
Comment 18 Mark Thomas 2018-05-29 14:34:33 UTC
It took a little longer than I expected but this is now implemented for 9.0.x