[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-users] Jetty 9 embedded Servlet 3.0 annotations without war file
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Jan,
thanks for your interesting reply!
I recognized the using-annotations docu of Jetty also, and thinked again now about the possibility
to configure a containerIncludeJarPattern.
At the end - it might work, but the code would depend on the file name of the jar, which is either
hardcoded or a startup parameter, which makes thinks more complicated, depending on how the final
application will be started.
To make it work at developing time, where is no jar file yet - I would have to point to the output
directory where the class files will be compiled into. This means that the code would depend on
the used build scenario (maven, ant dir structure, etc), additionaly as an alternative to the jar
name.
I personally think good code should be independent from these, at least for an embedded server
scenario, where the main goal is to be independent from external resources. If I have no problem
to depend on external file resources, then the better/cleaner solution would be to build the war
file and point to it, as this is the common standard for this.
best
Christian
On 16.01.2015 19:01, Jan Bartel wrote:
> Have a read of this page, which describes the important distinctions between discovered
> annotations, introspected annotations and ServletContainerInitializers:
> http://www.eclipse.org/jetty/documentation/current/using-annotations.html
>
> There is also a worked example on how to use annotations in an embedded scenario. The example
> code shown is for a webapp packaged as a war (and of course you can skip setup of jndi
> resources, login services etc if you don't need them). Your configuration will change if you
> aren't deploying an assembled war. In that case, you need to figure out if you're trying to
> support discovered annotations and ServletContainerInitializers. If so, then these are on the
> classpath of the executing embedding code, and considered as the equivalent of the container
> classpath. You just need to figure out a pattern for the
> "org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern" context attribute value that will
> match the class dirs on the container classpath.
>
> Others have used annotations with this type of embedding when createing an executable jar and
> have managed to find suitable settings for the ContainerIncludeJarPattern - try googling the
> jetty lists for postings about this. I might have also responded on StackOverflow to questions
> about this, so try googling that there too.
>
>
> regards Jan
>
> On 16 January 2015 at 17:16, Christian Reuschling <reuschling@xxxxxxxxxxxxxx> wrote: indeed, I
> tried to use Johannes code, and it seemed to work well, but @MultipartConfig was not
> recognized. I used WebAppContext instead of ServletContextHandler, but this didn't do the
> trick:
>
>
>
> WebAppContext contextHandler = new WebAppContext(); contextHandler.setContextPath("/");
> contextHandler.setResourceBase(".");
>
> server.setHandler(contextHandler);
>
> // unnecessary, servlet will be started during annotation scanning //
> contextHandler.addServlet(new ServletHolder(new ExampleDispatcherServlet()), "/*");
>
>
> Set<AnnotationParser.Handler> handlers = new HashSet<>(); handlers.add(new
> WebServletAnnotationHandler(contextHandler)); handlers.add(new
> WebFilterAnnotationHandler(contextHandler)); handlers.add(new
> WebListenerAnnotationHandler(contextHandler));
>
> AnnotationParser annotationParser = new AnnotationParser(); annotationParser.parse(handlers,
> ExampleDispatcherServlet.class.getName(), new ClassNameResolver() { @Override public boolean
> shouldOverride(String name) { return false; } @Override public boolean isExcluded(String name)
> { return false; } });
>
> server.start();
>
>
> The @WebInitParams were recognized, the servlet was loaded on startup. But no Multipart
> support. What will do the trick? I could manually add Multipart support with this hack:
>
>
> WebAppContext contextHandler = new WebAppContext() { @Override public void doHandle(String
> target, Request baseRequest, HttpServletRequest request, HttpServletResponse response) throws
> IOException, ServletException { String contentType = request.getHeader("Content-Type");
> if(contentType != null && contentType.startsWith("multipart/form-data")) {
> baseRequest.setAttribute(Request.__MULTIPART_CONFIG_ELEMENT, new
> MultipartConfigElement(System.getProperty("java.io.tmpdir"))); }
>
> super.doHandle(target, baseRequest, request, response); } };
>
>
> but it doesn't feel like a final solution.
>
> by the way - is it planed to scan servlet 3.0 annotations by Jetty inside the addServlet(..)
> methods in the future? It's a gap, isn't it?
>
>
> Christian
>
>
> On 16.01.2015 16:50, Joakim Erdfelt wrote:
>>>> Traditionally annotation scanning is part of the WebApp layer. Embedded Jetty focuses on
>>>> direct declarations.
>>>>
>>>> Johannes Brodwall's solution is creative, but only addresses a small subset of what, and
>>>> how, annotations can be wired up. (which might be sufficient in most cases) Examples: *
>>>> There's no good way to handle @HandlesType and ServletContainerInitializer his way. *
>>>> There's no support for @MultipartConfig without a WebAppContext.metadata to hold that
>>>> information * There's no support for @ServletSecurity without a WebAppContext.metadata to
>>>> hold that information
>>>>
>>>> Your example, however, uses @MultipartConfig, which is something that belongs in the
>>>> WebAppContext's metadata. That information, found during annotation scanning, isn't
>>>> retained in a ServletContextHandler.
>>>>
>>>>
>>>> -- Joakim Erdfelt <joakim@xxxxxxxxxxx <mailto:joakim@xxxxxxxxxxx>> webtide.com
>>>> <http://www.webtide.com/> - intalio.com/jetty <http://intalio.com/jetty> Expert advice,
>>>> services and support from from the Jetty & CometD experts eclipse.org/jetty
>>>> <http://eclipse.org/jetty/> - cometd.org <http://cometd.org/>
>>>>
>>>> On Fri, Jan 16, 2015 at 7:26 AM, Christian Reuschling <reuschling@xxxxxxxxxxxxxx
>>>> <mailto:reuschling@xxxxxxxxxxxxxx>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> we have no war file, nor some extra classpath, but simply want to add our servlet object
>>>> instance to the embedded server, by taking it's servlet 3.0 parameters into account.
>>>>
>>>> All the documentation on Jetty, and all examples and snippets we found for embedded +
>>>> servlet 3.0 annotations deals with specifying a war file or a classpath, which will be
>>>> scanned by AnnotationConfiguration then.
>>>>
>>>> We tried a lot, but we were not able to do the same by simply adding the servlet with
>>>> context.addServlet().
>>>>
>>>> Here is our code:
>>>>
>>>>
>>>> Server server = new Server(iPort);
>>>>
>>>> // tried: ServletHandler handler = new ServletHandler(); // tried: WebAppContext
>>>> contextHandler = new WebAppContext(); ServletContextHandler contextHandler = new
>>>> ServletContextHandler(); contextHandler.setContextPath("/");
>>>>
>>>> // tried: contextHandler.setConfigurations(new Configuration[] { // new
>>>> AnnotationConfiguration() }); // tried: contextHandler.setConfigurationDiscovered(true);
>>>>
>>>> contextHandler.addServlet(new ServletHolder(new ExampleServlet()), "/*");
>>>> server.setHandler(contextHandler);
>>>>
>>>> server.start();
>>>>
>>>>
>>>> The Servlet is a simple HttpServlet with following annotations:
>>>>
>>>> @WebServlet(urlPatterns = { "/example/*" }, loadOnStartup = 1, initParams = {
>>>> @WebInitParam(name = "name1", value = "val1"), @WebInitParam(name = "name2", value =
>>>> "val2") }) @MultipartConfig(fileSizeThreshold = 1024*1024*10) public class ExampleServlet
>>>> extends HttpServlet {....}
>>>>
>>>>
>>>>
>>>> How is it possible that the embedded Jetty server simply takes the annotations of the
>>>> Servlet Object added to the server with context/handler.addServlet(..) into account, and
>>>> nothing else, as the most simple scenario.
>>>>
>>>>
>>>> Thanks for all answers!
>>>>
>>>> Christian
>>>>
>>>>
>>>>
>>>> _______________________________________________ jetty-users mailing list
>>>> jetty-users@xxxxxxxxxxx <mailto:jetty-users@xxxxxxxxxxx> To change your delivery
>>>> options, retrieve your password, or unsubscribe from this list, visit
>>>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________ jetty-users mailing list
>>>> jetty-users@xxxxxxxxxxx To change your delivery options, retrieve your password, or
>>>> unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
>>>>
>
>> _______________________________________________ jetty-users mailing list
>> jetty-users@xxxxxxxxxxx To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
>
>
>
- --
______________________________________________________________________________
Christian Reuschling, Dipl.-Ing.(BA)
Software Engineer
Knowledge Management Department
German Research Center for Artificial Intelligence DFKI GmbH
Trippstadter Straße 122, D-67663 Kaiserslautern, Germany
Phone: +49.631.20575-1250
mailto:reuschling@xxxxxxx http://www.dfki.uni-kl.de/~reuschling/
- ------------Legal Company Information Required by German Law------------------
Geschäftsführung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313=
______________________________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlS85mYACgkQ6EqMXq+WZg/cVgCfaEapbth52EtPJ6FHw3ciIG/z
J4MAniapHvtDb9CFicSrvpM0LdmceT1j
=95Ik
-----END PGP SIGNATURE-----
