-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 <[email protected] <mailto:[email protected]>> 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 
> <[email protected] 
> <mailto:[email protected]>> 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 
> [email protected] <mailto:[email protected]> 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 
> [email protected] 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:[email protected]  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)

iEYEARECAAYFAlS5OVwACgkQ6EqMXq+WZg8NRQCghGezR7YmFFRHJIKS1Y31WclA
8HUAn0hTuOUMLXj/roGWPg6NNL84+yqJ
=ru1b
-----END PGP SIGNATURE-----
_______________________________________________
jetty-users mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

Reply via email to