Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 364850 - OSGiAppProvider can't redefine webdefault.xml
Summary: OSGiAppProvider can't redefine webdefault.xml
Status: RESOLVED FIXED
Alias: None
Product: Jetty
Classification: RT
Component: osgi (show other bugs)
Version: 7.5.4   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 7.5.x   Edit
Assignee: Jan Bartel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-25 10:48 EST by vgarnashevich CLA
Modified: 2012-03-21 23:34 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description vgarnashevich CLA 2011-11-25 10:48:24 EST
Build Identifier: 7.5.4.v20111024

Setting defaultsDescriptor on OSGiAppProvider has no effect. This setting is not applied to the created WebAppContext instance. After WebAppContext is created and published as an OSGi service, JettyContextHandlerServiceTracker receives a notification about that, and since the OSGi service registration does not have "defaultWebXmlFilePath" property set, it assumes default location, as for any normal web application, i.e. org/eclipse/jetty/webapp/webdefault.xml. Then, when it calls WebBundleDeployerHelper to register web application, it sees that defaultWebXmlPath is already specified and does not applies OSGiAppProvider's value. So in the end, the jetty's internal webdefault.xml is always used.

My current workaround is to extend OSGiAppProvider with my own class and in overridden addContext() method set the OSGiAppProvider's defaultsDescriptor to WebAppContext, in the place near extractWAR property is being set.


Reproducible: Always

Steps to Reproduce:
1. Use jetty, with jetty.osgi.boot.
2. In jetty.xml, in OSGiAppProvider's configuration set a value for defaultsDescriptor property.
3. The property value is ignored.
Comment 1 Jan Bartel CLA 2012-03-14 03:01:27 EDT
I believe this is fixed in release 7.6.2.v20120308.

Can you verify that fix? If so, I will close this issue.

thanks
Jan
Comment 2 Jan Bartel CLA 2012-03-21 23:34:19 EDT
Nevermind, I tested it an confirmed it was fixed in 7.6.2/8.1.2.