Bugzilla – Full Text Bug Listing
| Summary: | Get rid of javax.activation | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [RT] Jetty | Reporter: | Alexander Kurtakov <akurtakov> | ||||
| Component: | build | Assignee: | Hugues Malphettes <hmalphettes> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | jesse.mcconnell, jetty-inbox | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 7.5.x | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
applied to jetty 7 master will work into 8 on next merge Hugues.. I reopened to make sure it passed muster with your osgi bits, close it out if your fine with it. [16:11:44] <jmcconnell> I am wondering if the removal from the osgi ones are going to mess anything up [16:11:58] <jmcconnell> do eclipse osgi thing generally track javax.activation? [16:13:15] <jmcconnell> or is it an assumed part of the jdk6 for osgi environments [16:13:25] <akurtakov__> jmcconnell: well, osgi recommendations are to do Import-Package instead of Require-Bundle [16:13:48] <akurtakov__> if Import Package is used and the jvm provides it [16:13:51] <akurtakov__> there is no problem [16:14:04] <jmcconnell> ok, I'll reopen and follow up with hugues on it, its committed now, we just might have to adjust the bundles a bit [16:14:26] <jmcconnell> going to paste this dialog into the issue, that ok with you? [16:15:39] <akurtakov__> sure [16:15:54] <akurtakov__> jmcconnell: without knowing anything about osgi webmodules [16:16:10] <akurtakov__> I haven't found a single place importing javax.activation in an osgi well [16:16:27] <akurtakov__> if the metadata is somehow hidden I may have missed it (In reply to comment #2) > Hugues.. > > I reopened to make sure it passed muster with your osgi bits, close it out if > your fine with it. > > [16:13:48] <akurtakov__> if Import Package is used and the jvm provides it Yes we need to generate an Import-Package statement for javax.activation to follow the OSGi rules. > [16:13:51] <akurtakov__> there is no problem > [16:14:04] <jmcconnell> ok, I'll reopen and follow up with hugues on it, its > committed now, we just might have to adjust the bundles a bit > [16:14:26] <jmcconnell> going to paste this dialog into the issue, that ok with > you? > [16:15:39] <akurtakov__> sure > [16:15:54] <akurtakov__> jmcconnell: without knowing anything about osgi > webmodules > [16:16:10] <akurtakov__> I haven't found a single place importing > javax.activation in an osgi well > [16:16:27] <akurtakov__> if the metadata is somehow hidden I may have missed it A majority of the jetty projects generate the MANIFEST during the build with the BND maven plugin. In OSGi javax.activation is a very tricky case. Difficulties arise related to the javax.mail mime types stored in the META-INF folder: META-INF/mimetypes.default META-INF/mailcap I have reviewed the commit: http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/commit/?id=fae4f3fda93cbe2b0fe6dec42c1dec54a491c69a And it won't affect the OSGi build that will keep bundling javax.activation packaged in orbit. I don't know on the top of my head if a classic java runtime (URLClassloader); you would need some extra files to support the javax.mail mime types that users expect out of the box or not. (In reply to comment #3) > (In reply to comment #2) > > Hugues.. > > > > I reopened to make sure it passed muster with your osgi bits, close it out if > > your fine with it. > > > > [16:13:48] <akurtakov__> if Import Package is used and the jvm provides it > Yes we need to generate an Import-Package statement for javax.activation to > follow the OSGi rules. > > [16:13:51] <akurtakov__> there is no problem > > > > [16:14:04] <jmcconnell> ok, I'll reopen and follow up with hugues on it, its > > committed now, we just might have to adjust the bundles a bit > > [16:14:26] <jmcconnell> going to paste this dialog into the issue, that ok with > > you? > > [16:15:39] <akurtakov__> sure > > [16:15:54] <akurtakov__> jmcconnell: without knowing anything about osgi > > webmodules > > [16:16:10] <akurtakov__> I haven't found a single place importing > > javax.activation in an osgi well > > [16:16:27] <akurtakov__> if the metadata is somehow hidden I may have missed it > > A majority of the jetty projects generate the MANIFEST during the build with > the BND maven plugin. > > In OSGi javax.activation is a very tricky case. Difficulties arise related to > the javax.mail mime types stored in the META-INF folder: > META-INF/mimetypes.default META-INF/mailcap > > I have reviewed the commit: > http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/commit/?id=fae4f3fda93cbe2b0fe6dec42c1dec54a491c69a > And it won't affect the OSGi build that will keep bundling javax.activation > packaged in orbit. > > I don't know on the top of my head if a classic java runtime (URLClassloader); > you would need some extra files to support the javax.mail mime types that users > expect out of the box or not. The javax.activation change should not affect javax.mail registration and etc. because they should be taken care when loading the javax.mail which is always a separate bundle/jar. closing this out then, we'll need to make sure that equinox folks give the forthcoming M5 release a test out to make sure there isn't anything lingering (In reply to comment #4) > > The javax.activation change should not affect javax.mail registration and etc. > because they should be taken care when loading the javax.mail which is always a > separate bundle/jar. I remember spending hours debugging why javax.mail was not loading the mailcap ad mimes files. J2EE make a lot of assumptions that don't work in the modular world of OSGi. The orbit guys fixed the issue nicely. |
Created attachment 209484 [details] Proposed patch Java activation framework (JAF) or javax.activation:activation(maven) is an API that is integral part of every Java 5 level virtual machine. As such there is no point in still referencing/downloading/including or making any other operation with it. Simply removing references to it in build scripts makes it use the JVM provided one. The attached patch is doing exactly this.