Bugzilla – Full Text Bug Listing
| Summary: | Servlet 3.0 features should be easier to use when embedding / non-standard deployments | ||
|---|---|---|---|
| Product: | [RT] Jetty | Reporter: | Eirik Bjørsnøs <eirbjo> |
| Component: | server | Assignee: | Jan Bartel <janb> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | digulla, gregw, jetty-inbox |
| Version: | unspecified | ||
| Target Milestone: | 7.2.x | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
|
Description
Eirik Bjørsnøs
See also thread on jetty-dev: http://dev.eclipse.org/mhonarc/lists/jetty-dev/msg00902.html The difficulty here is that in an embedded scenario such as Eclipse, the classloaders used are not URLClassloaders, therefore we cannot retrieve the list of jars as urls and apply the pattern match for the container jars. I'm not looking for the one and only solution for all cases here :-)
What I would like is just to make the typical Jetty-in-main-method case easier.
Something like an EmbeddedConfiguration class which locates META-INF/resources on the classpath would be fine. It could probably inherit much of its code from jetty:run
Think:
WebAppContext ctx = new WebAppContext("src/main/webapp/", "/");
// Enable Servlet3.0 for embedded use where jar are not in WEB-INF/lib
ctx.addConfigurationClass(EmbeddedServlet3Configuration.class);
server.setHandler(ctx);
server.start();
Without this, Jetty is pretty much broken with the quick-start-from-main-method case..
Then we could probably add another configuration (OsgiConfiguration) which inspects bundles for META-INF/resources.
There are two aspects of this I think: 1) making sure that all the configuration classes are set that are needed 2) parameterizing the configuration - for example by telling it of jars to scan or fragments that exist outside of the normal webapplication structure. I'm not sure there is much we want to do here in jetty-8, but we can potentially be rather radical with jetty-9. For example, I wonder if the context really needs to array of configuration classes anymore - it really should just of a List of Configuration instances and we can make a simple factory (used by the deployer or set by default) to instantiate the configuration list. Once we simplify and update the context to just have a List of configuration, then it is much simpler to add instances to that. Some of these instances could indeed be utility instances designed to inject parameters such as searching outside of the webapp structure. Would something in the Jetty-9 time frame be OK? (beta release next month, stable release end of year). Hi Eirik, I think the later versions of jetty-9 support this via the WebInfConfiguration.CONTAINER_JAR_PATTERN. We will scan any jar whose name matches the pattern for META-INF/resources, META-INF/fragment.xml, META-INF/*.tlds. I know there are users who are using jetty in an embedded fashion via a runnable jar, so it seems to me we support this use-case. I'm going to close this issue, but feel free to reopen and attach a test harness to reproduce the problem and I'll take another look. cheers Jan WebInfConfiguration.CONTAINER_JAR_PATTERN doesn't work for projects (i.e. class folders) on the classpath. My use case: Start my app in the IDE as normal Java process. That means I have half of the code in projects open in the workspace which end up on the classpath. There are some places in Jetty which now fail to work, for example loading web-fragment.xml since there is a check which rejects the JAR when it's not in the WEB-INF/lib/ folder. I've found a solution for projects that contain web-fragment.xml. See this gist: https://gist.github.com/digulla/fb69b5df3b120f6e47b06130842d62cb Hi Aaron, Jetty has moved to using git issues instead, so can you raise one over at https://github.com/eclipse/jetty.project/issues thanks |