From matzew at redhat.com  Sun Feb  2 06:58:14 2014
From: matzew at redhat.com (Matthias Wessendorf)
Date: Sun, 2 Feb 2014 06:58:14 -0500 (EST)
Subject: [undertow-dev] serving static files
In-Reply-To: <1922757955.17405736.1391342175805.JavaMail.root@redhat.com>
Message-ID: <1971447378.17406083.1391342294137.JavaMail.root@redhat.com>

Hello,

I might be just doing it wrong, but the following attempts are not successful for serving static files from a folder:


        UndertowJaxrsServer ut = new UndertowJaxrsServer();
 
        MyRestApplication app = new MyRestApplication();
 
        ut.deploy(app);
 
        ut.start(
                Undertow.builder()
                        .addHttpListener(8080, "0.0.0.0")

 
                // first tried this:
                        .setHandler(path()
                                    .addPrefixPath("/",resource(new FileResourceManager(new File("/some/folder/containing/html/files"), 1024))))
 

                // afterwards also tried this:
                        .setHandler(resource(new FileResourceManager(new File("/some/folder/containing/html/files"), 1024)))
        );
 
        try {
            Thread.currentThread().join();
        }
        catch (InterruptedException e) {
            logger.info("shutting down");
            ut.stop();
        }




Not sure, but none of the above handlers seems to server files from a folder on my box


Greetings,
Matthias





-- 
Matthias Wessendorf
matzew at redhat.com

JBoss, by Red Hat

From sdouglas at redhat.com  Sun Feb  2 12:37:59 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Sun, 2 Feb 2014 12:37:59 -0500 (EST)
Subject: [undertow-dev] serving static files
In-Reply-To: <1971447378.17406083.1391342294137.JavaMail.root@redhat.com>
References: <1971447378.17406083.1391342294137.JavaMail.root@redhat.com>
Message-ID: <730639716.9940460.1391362679920.JavaMail.root@redhat.com>

I just added a file serving example to the Undertow examples, can you try that out and let me know if it works for you?

Just get the latest Undertow, build the examples, then run:

mvn exec:exec 

And select the file serving one, it should serve up you home directory.

Stuart

----- Original Message -----
> From: "Matthias Wessendorf" <matzew at redhat.com>
> To: undertow-dev at lists.jboss.org
> Sent: Sunday, 2 February, 2014 1:58:14 PM
> Subject: [undertow-dev] serving static files
> 
> Hello,
> 
> I might be just doing it wrong, but the following attempts are not successful
> for serving static files from a folder:
> 
> 
>         UndertowJaxrsServer ut = new UndertowJaxrsServer();
>  
>         MyRestApplication app = new MyRestApplication();
>  
>         ut.deploy(app);
>  
>         ut.start(
>                 Undertow.builder()
>                         .addHttpListener(8080, "0.0.0.0")
> 
>  
>                 // first tried this:
>                         .setHandler(path()
>                                     .addPrefixPath("/",resource(new
>                                     FileResourceManager(new
>                                     File("/some/folder/containing/html/files"),
>                                     1024))))
>  
> 
>                 // afterwards also tried this:
>                         .setHandler(resource(new FileResourceManager(new
>                         File("/some/folder/containing/html/files"), 1024)))
>         );
>  
>         try {
>             Thread.currentThread().join();
>         }
>         catch (InterruptedException e) {
>             logger.info("shutting down");
>             ut.stop();
>         }
> 
> 
> 
> 
> Not sure, but none of the above handlers seems to server files from a folder
> on my box
> 
> 
> Greetings,
> Matthias
> 
> 
> 
> 
> 
> --
> Matthias Wessendorf
> matzew at redhat.com
> 
> JBoss, by Red Hat
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

From matzew at redhat.com  Mon Feb  3 01:39:11 2014
From: matzew at redhat.com (Matthias Wessendorf)
Date: Mon, 3 Feb 2014 01:39:11 -0500 (EST)
Subject: [undertow-dev] serving static files
In-Reply-To: <730639716.9940460.1391362679920.JavaMail.root@redhat.com>
References: <1971447378.17406083.1391342294137.JavaMail.root@redhat.com>
	<730639716.9940460.1391362679920.JavaMail.root@redhat.com>
Message-ID: <537948257.17560402.1391409551725.JavaMail.root@redhat.com>

HEllo,

that works fine - however trying the same in my 'test': does not work :-/


        UndertowJaxrsServer ut = new UndertowJaxrsServer();

        TestApplication ta = new TestApplication();

        ut.deploy(ta);

        ut.start(
                Undertow.builder()
                        .addHttpListener(8080, "localhost")
                        .setHandler(resource(new FileResourceManager(new File(System.getProperty("user.home")), 100))
                                .setDirectoryListingEnabled(true))


        );

        try {
            Thread.currentThread().join();
        }
        catch (InterruptedException e) {
            logger.info("shutting down");
            ut.stop();
        }




-Matthias




----- Original Message -----
> From: "Stuart Douglas" <sdouglas at redhat.com>
> To: "Matthias Wessendorf" <matzew at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Sunday, February 2, 2014 6:37:59 PM
> Subject: Re: [undertow-dev] serving static files
> 
> I just added a file serving example to the Undertow examples, can you try
> that out and let me know if it works for you?
> 
> Just get the latest Undertow, build the examples, then run:
> 
> mvn exec:exec
> 
> And select the file serving one, it should serve up you home directory.
> 
> Stuart
> 
> ----- Original Message -----
> > From: "Matthias Wessendorf" <matzew at redhat.com>
> > To: undertow-dev at lists.jboss.org
> > Sent: Sunday, 2 February, 2014 1:58:14 PM
> > Subject: [undertow-dev] serving static files
> > 
> > Hello,
> > 
> > I might be just doing it wrong, but the following attempts are not
> > successful
> > for serving static files from a folder:
> > 
> > 
> >         UndertowJaxrsServer ut = new UndertowJaxrsServer();
> >  
> >         MyRestApplication app = new MyRestApplication();
> >  
> >         ut.deploy(app);
> >  
> >         ut.start(
> >                 Undertow.builder()
> >                         .addHttpListener(8080, "0.0.0.0")
> > 
> >  
> >                 // first tried this:
> >                         .setHandler(path()
> >                                     .addPrefixPath("/",resource(new
> >                                     FileResourceManager(new
> >                                     File("/some/folder/containing/html/files"),
> >                                     1024))))
> >  
> > 
> >                 // afterwards also tried this:
> >                         .setHandler(resource(new FileResourceManager(new
> >                         File("/some/folder/containing/html/files"), 1024)))
> >         );
> >  
> >         try {
> >             Thread.currentThread().join();
> >         }
> >         catch (InterruptedException e) {
> >             logger.info("shutting down");
> >             ut.stop();
> >         }
> > 
> > 
> > 
> > 
> > Not sure, but none of the above handlers seems to server files from a
> > folder
> > on my box
> > 
> > 
> > Greetings,
> > Matthias
> > 
> > 
> > 
> > 
> > 
> > --
> > Matthias Wessendorf
> > matzew at redhat.com
> > 
> > JBoss, by Red Hat
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > 
> 

-- 
Matthias Wessendorf
matzew at redhat.com

JBoss, by Red Hat

From sdouglas at redhat.com  Mon Feb  3 02:39:08 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 3 Feb 2014 02:39:08 -0500 (EST)
Subject: [undertow-dev] serving static files
In-Reply-To: <537948257.17560402.1391409551725.JavaMail.root@redhat.com>
References: <1971447378.17406083.1391342294137.JavaMail.root@redhat.com>
	<730639716.9940460.1391362679920.JavaMail.root@redhat.com>
	<537948257.17560402.1391409551725.JavaMail.root@redhat.com>
Message-ID: <1200023593.10003438.1391413148352.JavaMail.root@redhat.com>

What does the rest of your code look like? And when you say it does not work, what sort of failure are you getting? A 404?

Stuart

----- Original Message -----
> From: "Matthias Wessendorf" <matzew at redhat.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Monday, 3 February, 2014 8:39:11 AM
> Subject: Re: [undertow-dev] serving static files
> 
> HEllo,
> 
> that works fine - however trying the same in my 'test': does not work :-/
> 
> 
>         UndertowJaxrsServer ut = new UndertowJaxrsServer();
> 
>         TestApplication ta = new TestApplication();
> 
>         ut.deploy(ta);
> 
>         ut.start(
>                 Undertow.builder()
>                         .addHttpListener(8080, "localhost")
>                         .setHandler(resource(new FileResourceManager(new
>                         File(System.getProperty("user.home")), 100))
>                                 .setDirectoryListingEnabled(true))
> 
> 
>         );
> 
>         try {
>             Thread.currentThread().join();
>         }
>         catch (InterruptedException e) {
>             logger.info("shutting down");
>             ut.stop();
>         }
> 
> 
> 
> 
> -Matthias
> 
> 
> 
> 
> ----- Original Message -----
> > From: "Stuart Douglas" <sdouglas at redhat.com>
> > To: "Matthias Wessendorf" <matzew at redhat.com>
> > Cc: undertow-dev at lists.jboss.org
> > Sent: Sunday, February 2, 2014 6:37:59 PM
> > Subject: Re: [undertow-dev] serving static files
> > 
> > I just added a file serving example to the Undertow examples, can you try
> > that out and let me know if it works for you?
> > 
> > Just get the latest Undertow, build the examples, then run:
> > 
> > mvn exec:exec
> > 
> > And select the file serving one, it should serve up you home directory.
> > 
> > Stuart
> > 
> > ----- Original Message -----
> > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > To: undertow-dev at lists.jboss.org
> > > Sent: Sunday, 2 February, 2014 1:58:14 PM
> > > Subject: [undertow-dev] serving static files
> > > 
> > > Hello,
> > > 
> > > I might be just doing it wrong, but the following attempts are not
> > > successful
> > > for serving static files from a folder:
> > > 
> > > 
> > >         UndertowJaxrsServer ut = new UndertowJaxrsServer();
> > >  
> > >         MyRestApplication app = new MyRestApplication();
> > >  
> > >         ut.deploy(app);
> > >  
> > >         ut.start(
> > >                 Undertow.builder()
> > >                         .addHttpListener(8080, "0.0.0.0")
> > > 
> > >  
> > >                 // first tried this:
> > >                         .setHandler(path()
> > >                                     .addPrefixPath("/",resource(new
> > >                                     FileResourceManager(new
> > >                                     File("/some/folder/containing/html/files"),
> > >                                     1024))))
> > >  
> > > 
> > >                 // afterwards also tried this:
> > >                         .setHandler(resource(new FileResourceManager(new
> > >                         File("/some/folder/containing/html/files"),
> > >                         1024)))
> > >         );
> > >  
> > >         try {
> > >             Thread.currentThread().join();
> > >         }
> > >         catch (InterruptedException e) {
> > >             logger.info("shutting down");
> > >             ut.stop();
> > >         }
> > > 
> > > 
> > > 
> > > 
> > > Not sure, but none of the above handlers seems to server files from a
> > > folder
> > > on my box
> > > 
> > > 
> > > Greetings,
> > > Matthias
> > > 
> > > 
> > > 
> > > 
> > > 
> > > --
> > > Matthias Wessendorf
> > > matzew at redhat.com
> > > 
> > > JBoss, by Red Hat
> > > _______________________________________________
> > > undertow-dev mailing list
> > > undertow-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > > 
> > 
> 
> --
> Matthias Wessendorf
> matzew at redhat.com
> 
> JBoss, by Red Hat
> 

From matzew at redhat.com  Mon Feb  3 03:38:04 2014
From: matzew at redhat.com (Matthias Wessendorf)
Date: Mon, 3 Feb 2014 03:38:04 -0500 (EST)
Subject: [undertow-dev] serving static files
In-Reply-To: <1200023593.10003438.1391413148352.JavaMail.root@redhat.com>
References: <1971447378.17406083.1391342294137.JavaMail.root@redhat.com>
	<730639716.9940460.1391362679920.JavaMail.root@redhat.com>
	<537948257.17560402.1391409551725.JavaMail.root@redhat.com>
	<1200023593.10003438.1391413148352.JavaMail.root@redhat.com>
Message-ID: <709822249.17604936.1391416684157.JavaMail.root@redhat.com>

Hello Stuart,

I pushed my test to github. the 'main' is located here:
https://github.com/matzew/undertow-jaxrs-test/blob/master/src/main/java/net/wessendorf/undertow/App.java

When I run that and I am accessing "http://localhost:8080/status", all is fine, my 'StatusEndpoint' JAX-RS resource is executed and I get my response;
However, when I am hitting "http://localhost:8080" am getting 404 in the browser, and the following on the console in my IDE:


Feb 03, 2014 9:26:04 AM org.jboss.resteasy.core.ExceptionHandler 
SEVERE: failed to execute
javax.ws.rs.NotFoundException: Could not find resource for full path: http://localhost:8080/
	at org.jboss.resteasy.core.registry.ClassNode.match(ClassNode.java:73)
	at org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48)
	at org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:444)
	at org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:234)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:171)
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at java.lang.Thread.run(Thread.java:722)







So, looks like the JAX-RS is somewhat having an effect on the actual "FileResourceManager" that should serve my static files



-Matthias




----- Original Message -----
> From: "Stuart Douglas" <sdouglas at redhat.com>
> To: "Matthias Wessendorf" <matzew at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Monday, February 3, 2014 8:39:08 AM
> Subject: Re: [undertow-dev] serving static files
> 
> What does the rest of your code look like? And when you say it does not work,
> what sort of failure are you getting? A 404?
> 
> Stuart
> 
> ----- Original Message -----
> > From: "Matthias Wessendorf" <matzew at redhat.com>
> > To: "Stuart Douglas" <sdouglas at redhat.com>
> > Cc: undertow-dev at lists.jboss.org
> > Sent: Monday, 3 February, 2014 8:39:11 AM
> > Subject: Re: [undertow-dev] serving static files
> > 
> > HEllo,
> > 
> > that works fine - however trying the same in my 'test': does not work :-/
> > 
> > 
> >         UndertowJaxrsServer ut = new UndertowJaxrsServer();
> > 
> >         TestApplication ta = new TestApplication();
> > 
> >         ut.deploy(ta);
> > 
> >         ut.start(
> >                 Undertow.builder()
> >                         .addHttpListener(8080, "localhost")
> >                         .setHandler(resource(new FileResourceManager(new
> >                         File(System.getProperty("user.home")), 100))
> >                                 .setDirectoryListingEnabled(true))
> > 
> > 
> >         );
> > 
> >         try {
> >             Thread.currentThread().join();
> >         }
> >         catch (InterruptedException e) {
> >             logger.info("shutting down");
> >             ut.stop();
> >         }
> > 
> > 
> > 
> > 
> > -Matthias
> > 
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > Cc: undertow-dev at lists.jboss.org
> > > Sent: Sunday, February 2, 2014 6:37:59 PM
> > > Subject: Re: [undertow-dev] serving static files
> > > 
> > > I just added a file serving example to the Undertow examples, can you try
> > > that out and let me know if it works for you?
> > > 
> > > Just get the latest Undertow, build the examples, then run:
> > > 
> > > mvn exec:exec
> > > 
> > > And select the file serving one, it should serve up you home directory.
> > > 
> > > Stuart
> > > 
> > > ----- Original Message -----
> > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > To: undertow-dev at lists.jboss.org
> > > > Sent: Sunday, 2 February, 2014 1:58:14 PM
> > > > Subject: [undertow-dev] serving static files
> > > > 
> > > > Hello,
> > > > 
> > > > I might be just doing it wrong, but the following attempts are not
> > > > successful
> > > > for serving static files from a folder:
> > > > 
> > > > 
> > > >         UndertowJaxrsServer ut = new UndertowJaxrsServer();
> > > >  
> > > >         MyRestApplication app = new MyRestApplication();
> > > >  
> > > >         ut.deploy(app);
> > > >  
> > > >         ut.start(
> > > >                 Undertow.builder()
> > > >                         .addHttpListener(8080, "0.0.0.0")
> > > > 
> > > >  
> > > >                 // first tried this:
> > > >                         .setHandler(path()
> > > >                                     .addPrefixPath("/",resource(new
> > > >                                     FileResourceManager(new
> > > >                                     File("/some/folder/containing/html/files"),
> > > >                                     1024))))
> > > >  
> > > > 
> > > >                 // afterwards also tried this:
> > > >                         .setHandler(resource(new
> > > >                         FileResourceManager(new
> > > >                         File("/some/folder/containing/html/files"),
> > > >                         1024)))
> > > >         );
> > > >  
> > > >         try {
> > > >             Thread.currentThread().join();
> > > >         }
> > > >         catch (InterruptedException e) {
> > > >             logger.info("shutting down");
> > > >             ut.stop();
> > > >         }
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Not sure, but none of the above handlers seems to server files from a
> > > > folder
> > > > on my box
> > > > 
> > > > 
> > > > Greetings,
> > > > Matthias
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > --
> > > > Matthias Wessendorf
> > > > matzew at redhat.com
> > > > 
> > > > JBoss, by Red Hat
> > > > _______________________________________________
> > > > undertow-dev mailing list
> > > > undertow-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > > > 
> > > 
> > 
> > --
> > Matthias Wessendorf
> > matzew at redhat.com
> > 
> > JBoss, by Red Hat
> > 
> 

-- 
Matthias Wessendorf
matzew at redhat.com

JBoss, by Red Hat

From sdouglas at redhat.com  Mon Feb  3 03:57:42 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 3 Feb 2014 03:57:42 -0500 (EST)
Subject: [undertow-dev] serving static files
In-Reply-To: <709822249.17604936.1391416684157.JavaMail.root@redhat.com>
References: <1971447378.17406083.1391342294137.JavaMail.root@redhat.com>
	<730639716.9940460.1391362679920.JavaMail.root@redhat.com>
	<537948257.17560402.1391409551725.JavaMail.root@redhat.com>
	<1200023593.10003438.1391413148352.JavaMail.root@redhat.com>
	<709822249.17604936.1391416684157.JavaMail.root@redhat.com>
Message-ID: <1505628887.10018293.1391417862661.JavaMail.root@redhat.com>

This is the code from the Resteasy Undertow server:

   public UndertowJaxrsServer start(Undertow.Builder builder)
   {
      server = builder.setHandler(root).build();
      server.start();
      return this;
   }

So basically when you call start the servlet container is always registered as the root resource. 


Stuart

----- Original Message -----
> From: "Matthias Wessendorf" <matzew at redhat.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Monday, 3 February, 2014 10:38:04 AM
> Subject: Re: [undertow-dev] serving static files
> 
> Hello Stuart,
> 
> I pushed my test to github. the 'main' is located here:
> https://github.com/matzew/undertow-jaxrs-test/blob/master/src/main/java/net/wessendorf/undertow/App.java
> 
> When I run that and I am accessing "http://localhost:8080/status", all is
> fine, my 'StatusEndpoint' JAX-RS resource is executed and I get my response;
> However, when I am hitting "http://localhost:8080" am getting 404 in the
> browser, and the following on the console in my IDE:
> 
> 
> Feb 03, 2014 9:26:04 AM org.jboss.resteasy.core.ExceptionHandler
> SEVERE: failed to execute
> javax.ws.rs.NotFoundException: Could not find resource for full path:
> http://localhost:8080/
> 	at org.jboss.resteasy.core.registry.ClassNode.match(ClassNode.java:73)
> 	at
> 	org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48)
> 	at
> 	org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:444)
> 	at
> 	org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:234)
> 	at
> 	org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:171)
> 	at
> 	org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> 	at
> 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> 	at
> 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 	at
> 	io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 	at
> 	io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> 	at
> 	io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 	at
> 	io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> 	at
> 	io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> 	at
> 	io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> 	at
> 	io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> 	at
> 	io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> 	at
> 	io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> 	at
> 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> 	at
> 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> 	at
> 	io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
> 	at
> 	io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> 	at
> 	io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> 	at
> 	io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
> 	at
> 	java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> 	at
> 	java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> 	at java.lang.Thread.run(Thread.java:722)
> 
> 
> 
> 
> 
> 
> 
> So, looks like the JAX-RS is somewhat having an effect on the actual
> "FileResourceManager" that should serve my static files
> 
> 
> 
> -Matthias
> 
> 
> 
> 
> ----- Original Message -----
> > From: "Stuart Douglas" <sdouglas at redhat.com>
> > To: "Matthias Wessendorf" <matzew at redhat.com>
> > Cc: undertow-dev at lists.jboss.org
> > Sent: Monday, February 3, 2014 8:39:08 AM
> > Subject: Re: [undertow-dev] serving static files
> > 
> > What does the rest of your code look like? And when you say it does not
> > work,
> > what sort of failure are you getting? A 404?
> > 
> > Stuart
> > 
> > ----- Original Message -----
> > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > To: "Stuart Douglas" <sdouglas at redhat.com>
> > > Cc: undertow-dev at lists.jboss.org
> > > Sent: Monday, 3 February, 2014 8:39:11 AM
> > > Subject: Re: [undertow-dev] serving static files
> > > 
> > > HEllo,
> > > 
> > > that works fine - however trying the same in my 'test': does not work :-/
> > > 
> > > 
> > >         UndertowJaxrsServer ut = new UndertowJaxrsServer();
> > > 
> > >         TestApplication ta = new TestApplication();
> > > 
> > >         ut.deploy(ta);
> > > 
> > >         ut.start(
> > >                 Undertow.builder()
> > >                         .addHttpListener(8080, "localhost")
> > >                         .setHandler(resource(new FileResourceManager(new
> > >                         File(System.getProperty("user.home")), 100))
> > >                                 .setDirectoryListingEnabled(true))
> > > 
> > > 
> > >         );
> > > 
> > >         try {
> > >             Thread.currentThread().join();
> > >         }
> > >         catch (InterruptedException e) {
> > >             logger.info("shutting down");
> > >             ut.stop();
> > >         }
> > > 
> > > 
> > > 
> > > 
> > > -Matthias
> > > 
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > > Cc: undertow-dev at lists.jboss.org
> > > > Sent: Sunday, February 2, 2014 6:37:59 PM
> > > > Subject: Re: [undertow-dev] serving static files
> > > > 
> > > > I just added a file serving example to the Undertow examples, can you
> > > > try
> > > > that out and let me know if it works for you?
> > > > 
> > > > Just get the latest Undertow, build the examples, then run:
> > > > 
> > > > mvn exec:exec
> > > > 
> > > > And select the file serving one, it should serve up you home directory.
> > > > 
> > > > Stuart
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > To: undertow-dev at lists.jboss.org
> > > > > Sent: Sunday, 2 February, 2014 1:58:14 PM
> > > > > Subject: [undertow-dev] serving static files
> > > > > 
> > > > > Hello,
> > > > > 
> > > > > I might be just doing it wrong, but the following attempts are not
> > > > > successful
> > > > > for serving static files from a folder:
> > > > > 
> > > > > 
> > > > >         UndertowJaxrsServer ut = new UndertowJaxrsServer();
> > > > >  
> > > > >         MyRestApplication app = new MyRestApplication();
> > > > >  
> > > > >         ut.deploy(app);
> > > > >  
> > > > >         ut.start(
> > > > >                 Undertow.builder()
> > > > >                         .addHttpListener(8080, "0.0.0.0")
> > > > > 
> > > > >  
> > > > >                 // first tried this:
> > > > >                         .setHandler(path()
> > > > >                                     .addPrefixPath("/",resource(new
> > > > >                                     FileResourceManager(new
> > > > >                                     File("/some/folder/containing/html/files"),
> > > > >                                     1024))))
> > > > >  
> > > > > 
> > > > >                 // afterwards also tried this:
> > > > >                         .setHandler(resource(new
> > > > >                         FileResourceManager(new
> > > > >                         File("/some/folder/containing/html/files"),
> > > > >                         1024)))
> > > > >         );
> > > > >  
> > > > >         try {
> > > > >             Thread.currentThread().join();
> > > > >         }
> > > > >         catch (InterruptedException e) {
> > > > >             logger.info("shutting down");
> > > > >             ut.stop();
> > > > >         }
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Not sure, but none of the above handlers seems to server files from a
> > > > > folder
> > > > > on my box
> > > > > 
> > > > > 
> > > > > Greetings,
> > > > > Matthias
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > --
> > > > > Matthias Wessendorf
> > > > > matzew at redhat.com
> > > > > 
> > > > > JBoss, by Red Hat
> > > > > _______________________________________________
> > > > > undertow-dev mailing list
> > > > > undertow-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > > > > 
> > > > 
> > > 
> > > --
> > > Matthias Wessendorf
> > > matzew at redhat.com
> > > 
> > > JBoss, by Red Hat
> > > 
> > 
> 
> --
> Matthias Wessendorf
> matzew at redhat.com
> 
> JBoss, by Red Hat
> 

From matzew at redhat.com  Mon Feb  3 04:12:30 2014
From: matzew at redhat.com (Matthias Wessendorf)
Date: Mon, 3 Feb 2014 04:12:30 -0500 (EST)
Subject: [undertow-dev] serving static files
In-Reply-To: <1505628887.10018293.1391417862661.JavaMail.root@redhat.com>
References: <1971447378.17406083.1391342294137.JavaMail.root@redhat.com>
	<730639716.9940460.1391362679920.JavaMail.root@redhat.com>
	<537948257.17560402.1391409551725.JavaMail.root@redhat.com>
	<1200023593.10003438.1391413148352.JavaMail.root@redhat.com>
	<709822249.17604936.1391416684157.JavaMail.root@redhat.com>
	<1505628887.10018293.1391417862661.JavaMail.root@redhat.com>
Message-ID: <454257937.17620291.1391418750370.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Stuart Douglas" <sdouglas at redhat.com>
> To: "Matthias Wessendorf" <matzew at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Monday, February 3, 2014 9:57:42 AM
> Subject: Re: [undertow-dev] serving static files
> 
> This is the code from the Resteasy Undertow server:
> 
>    public UndertowJaxrsServer start(Undertow.Builder builder)
>    {
>       server = builder.setHandler(root).build();
>       server.start();
>       return this;
>    }
> 
> So basically when you call start the servlet container is always registered
> as the root resource.

So, that means I am not able to provide a 'FileResourceManager' in that Undertow/RestEasy combination ?

> 
> 
> Stuart
> 
> ----- Original Message -----
> > From: "Matthias Wessendorf" <matzew at redhat.com>
> > To: "Stuart Douglas" <sdouglas at redhat.com>
> > Cc: undertow-dev at lists.jboss.org
> > Sent: Monday, 3 February, 2014 10:38:04 AM
> > Subject: Re: [undertow-dev] serving static files
> > 
> > Hello Stuart,
> > 
> > I pushed my test to github. the 'main' is located here:
> > https://github.com/matzew/undertow-jaxrs-test/blob/master/src/main/java/net/wessendorf/undertow/App.java
> > 
> > When I run that and I am accessing "http://localhost:8080/status", all is
> > fine, my 'StatusEndpoint' JAX-RS resource is executed and I get my
> > response;
> > However, when I am hitting "http://localhost:8080" am getting 404 in the
> > browser, and the following on the console in my IDE:
> > 
> > 
> > Feb 03, 2014 9:26:04 AM org.jboss.resteasy.core.ExceptionHandler
> > SEVERE: failed to execute
> > javax.ws.rs.NotFoundException: Could not find resource for full path:
> > http://localhost:8080/
> > 	at org.jboss.resteasy.core.registry.ClassNode.match(ClassNode.java:73)
> > 	at
> > 	org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48)
> > 	at
> > 	org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:444)
> > 	at
> > 	org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:234)
> > 	at
> > 	org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:171)
> > 	at
> > 	org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> > 	at
> > 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> > 	at
> > 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> > 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> > 	at
> > 	io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> > 	at
> > 	io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> > 	at
> > 	io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> > 	at
> > 	io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> > 	at
> > 	io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> > 	at
> > 	io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> > 	at
> > 	io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> > 	at
> > 	io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> > 	at
> > 	io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> > 	at
> > 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > 	at
> > 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > 	at
> > 	io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
> > 	at
> > 	io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> > 	at
> > 	io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> > 	at
> > 	io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> > 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168)
> > 	at
> > 	io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
> > 	at
> > 	java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> > 	at
> > 	java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> > 	at java.lang.Thread.run(Thread.java:722)
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > So, looks like the JAX-RS is somewhat having an effect on the actual
> > "FileResourceManager" that should serve my static files
> > 
> > 
> > 
> > -Matthias
> > 
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > Cc: undertow-dev at lists.jboss.org
> > > Sent: Monday, February 3, 2014 8:39:08 AM
> > > Subject: Re: [undertow-dev] serving static files
> > > 
> > > What does the rest of your code look like? And when you say it does not
> > > work,
> > > what sort of failure are you getting? A 404?
> > > 
> > > Stuart
> > > 
> > > ----- Original Message -----
> > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > To: "Stuart Douglas" <sdouglas at redhat.com>
> > > > Cc: undertow-dev at lists.jboss.org
> > > > Sent: Monday, 3 February, 2014 8:39:11 AM
> > > > Subject: Re: [undertow-dev] serving static files
> > > > 
> > > > HEllo,
> > > > 
> > > > that works fine - however trying the same in my 'test': does not work
> > > > :-/
> > > > 
> > > > 
> > > >         UndertowJaxrsServer ut = new UndertowJaxrsServer();
> > > > 
> > > >         TestApplication ta = new TestApplication();
> > > > 
> > > >         ut.deploy(ta);
> > > > 
> > > >         ut.start(
> > > >                 Undertow.builder()
> > > >                         .addHttpListener(8080, "localhost")
> > > >                         .setHandler(resource(new
> > > >                         FileResourceManager(new
> > > >                         File(System.getProperty("user.home")), 100))
> > > >                                 .setDirectoryListingEnabled(true))
> > > > 
> > > > 
> > > >         );
> > > > 
> > > >         try {
> > > >             Thread.currentThread().join();
> > > >         }
> > > >         catch (InterruptedException e) {
> > > >             logger.info("shutting down");
> > > >             ut.stop();
> > > >         }
> > > > 
> > > > 
> > > > 
> > > > 
> > > > -Matthias
> > > > 
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > Cc: undertow-dev at lists.jboss.org
> > > > > Sent: Sunday, February 2, 2014 6:37:59 PM
> > > > > Subject: Re: [undertow-dev] serving static files
> > > > > 
> > > > > I just added a file serving example to the Undertow examples, can you
> > > > > try
> > > > > that out and let me know if it works for you?
> > > > > 
> > > > > Just get the latest Undertow, build the examples, then run:
> > > > > 
> > > > > mvn exec:exec
> > > > > 
> > > > > And select the file serving one, it should serve up you home
> > > > > directory.
> > > > > 
> > > > > Stuart
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > To: undertow-dev at lists.jboss.org
> > > > > > Sent: Sunday, 2 February, 2014 1:58:14 PM
> > > > > > Subject: [undertow-dev] serving static files
> > > > > > 
> > > > > > Hello,
> > > > > > 
> > > > > > I might be just doing it wrong, but the following attempts are not
> > > > > > successful
> > > > > > for serving static files from a folder:
> > > > > > 
> > > > > > 
> > > > > >         UndertowJaxrsServer ut = new UndertowJaxrsServer();
> > > > > >  
> > > > > >         MyRestApplication app = new MyRestApplication();
> > > > > >  
> > > > > >         ut.deploy(app);
> > > > > >  
> > > > > >         ut.start(
> > > > > >                 Undertow.builder()
> > > > > >                         .addHttpListener(8080, "0.0.0.0")
> > > > > > 
> > > > > >  
> > > > > >                 // first tried this:
> > > > > >                         .setHandler(path()
> > > > > >                                     .addPrefixPath("/",resource(new
> > > > > >                                     FileResourceManager(new
> > > > > >                                     File("/some/folder/containing/html/files"),
> > > > > >                                     1024))))
> > > > > >  
> > > > > > 
> > > > > >                 // afterwards also tried this:
> > > > > >                         .setHandler(resource(new
> > > > > >                         FileResourceManager(new
> > > > > >                         File("/some/folder/containing/html/files"),
> > > > > >                         1024)))
> > > > > >         );
> > > > > >  
> > > > > >         try {
> > > > > >             Thread.currentThread().join();
> > > > > >         }
> > > > > >         catch (InterruptedException e) {
> > > > > >             logger.info("shutting down");
> > > > > >             ut.stop();
> > > > > >         }
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Not sure, but none of the above handlers seems to server files from
> > > > > > a
> > > > > > folder
> > > > > > on my box
> > > > > > 
> > > > > > 
> > > > > > Greetings,
> > > > > > Matthias
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > --
> > > > > > Matthias Wessendorf
> > > > > > matzew at redhat.com
> > > > > > 
> > > > > > JBoss, by Red Hat
> > > > > > _______________________________________________
> > > > > > undertow-dev mailing list
> > > > > > undertow-dev at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > > > > > 
> > > > > 
> > > > 
> > > > --
> > > > Matthias Wessendorf
> > > > matzew at redhat.com
> > > > 
> > > > JBoss, by Red Hat
> > > > 
> > > 
> > 
> > --
> > Matthias Wessendorf
> > matzew at redhat.com
> > 
> > JBoss, by Red Hat
> > 
> 

-- 
Matthias Wessendorf
matzew at redhat.com

JBoss, by Red Hat

From sdouglas at redhat.com  Mon Feb  3 04:16:16 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 3 Feb 2014 04:16:16 -0500 (EST)
Subject: [undertow-dev] serving static files
In-Reply-To: <454257937.17620291.1391418750370.JavaMail.root@redhat.com>
References: <1971447378.17406083.1391342294137.JavaMail.root@redhat.com>
	<730639716.9940460.1391362679920.JavaMail.root@redhat.com>
	<537948257.17560402.1391409551725.JavaMail.root@redhat.com>
	<1200023593.10003438.1391413148352.JavaMail.root@redhat.com>
	<709822249.17604936.1391416684157.JavaMail.root@redhat.com>
	<1505628887.10018293.1391417862661.JavaMail.root@redhat.com>
	<454257937.17620291.1391418750370.JavaMail.root@redhat.com>
Message-ID: <1678388693.10020906.1391418976723.JavaMail.root@redhat.com>

Yes and no. 

It looks like Bill has not added that capability into the Resteasy server, however you could use a ServletExtension to serve static files from certain paths: 

http://undertow.io/documentation/servlet/using-non-blocking-handlers-with-servlet.html

The other option would be to file a Resteasy JIRA (or better yet provide a pull request) to add more flexibility to the server. 

Stuart

----- Original Message -----
> From: "Matthias Wessendorf" <matzew at redhat.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Monday, 3 February, 2014 11:12:30 AM
> Subject: Re: [undertow-dev] serving static files
> 
> 
> 
> ----- Original Message -----
> > From: "Stuart Douglas" <sdouglas at redhat.com>
> > To: "Matthias Wessendorf" <matzew at redhat.com>
> > Cc: undertow-dev at lists.jboss.org
> > Sent: Monday, February 3, 2014 9:57:42 AM
> > Subject: Re: [undertow-dev] serving static files
> > 
> > This is the code from the Resteasy Undertow server:
> > 
> >    public UndertowJaxrsServer start(Undertow.Builder builder)
> >    {
> >       server = builder.setHandler(root).build();
> >       server.start();
> >       return this;
> >    }
> > 
> > So basically when you call start the servlet container is always registered
> > as the root resource.
> 
> So, that means I am not able to provide a 'FileResourceManager' in that
> Undertow/RestEasy combination ?
> 
> > 
> > 
> > Stuart
> > 
> > ----- Original Message -----
> > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > To: "Stuart Douglas" <sdouglas at redhat.com>
> > > Cc: undertow-dev at lists.jboss.org
> > > Sent: Monday, 3 February, 2014 10:38:04 AM
> > > Subject: Re: [undertow-dev] serving static files
> > > 
> > > Hello Stuart,
> > > 
> > > I pushed my test to github. the 'main' is located here:
> > > https://github.com/matzew/undertow-jaxrs-test/blob/master/src/main/java/net/wessendorf/undertow/App.java
> > > 
> > > When I run that and I am accessing "http://localhost:8080/status", all is
> > > fine, my 'StatusEndpoint' JAX-RS resource is executed and I get my
> > > response;
> > > However, when I am hitting "http://localhost:8080" am getting 404 in the
> > > browser, and the following on the console in my IDE:
> > > 
> > > 
> > > Feb 03, 2014 9:26:04 AM org.jboss.resteasy.core.ExceptionHandler
> > > SEVERE: failed to execute
> > > javax.ws.rs.NotFoundException: Could not find resource for full path:
> > > http://localhost:8080/
> > > 	at org.jboss.resteasy.core.registry.ClassNode.match(ClassNode.java:73)
> > > 	at
> > > 	org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48)
> > > 	at
> > > 	org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:444)
> > > 	at
> > > 	org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:234)
> > > 	at
> > > 	org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:171)
> > > 	at
> > > 	org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> > > 	at
> > > 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> > > 	at
> > > 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> > > 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> > > 	at
> > > 	io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> > > 	at
> > > 	io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> > > 	at
> > > 	io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> > > 	at
> > > 	io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> > > 	at
> > > 	io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> > > 	at
> > > 	io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> > > 	at
> > > 	io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> > > 	at
> > > 	io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> > > 	at
> > > 	io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> > > 	at
> > > 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > > 	at
> > > 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > > 	at
> > > 	io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
> > > 	at
> > > 	io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> > > 	at
> > > 	io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> > > 	at
> > > 	io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> > > 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168)
> > > 	at
> > > 	io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
> > > 	at
> > > 	java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> > > 	at
> > > 	java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> > > 	at java.lang.Thread.run(Thread.java:722)
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > So, looks like the JAX-RS is somewhat having an effect on the actual
> > > "FileResourceManager" that should serve my static files
> > > 
> > > 
> > > 
> > > -Matthias
> > > 
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > > Cc: undertow-dev at lists.jboss.org
> > > > Sent: Monday, February 3, 2014 8:39:08 AM
> > > > Subject: Re: [undertow-dev] serving static files
> > > > 
> > > > What does the rest of your code look like? And when you say it does not
> > > > work,
> > > > what sort of failure are you getting? A 404?
> > > > 
> > > > Stuart
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > To: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > Cc: undertow-dev at lists.jboss.org
> > > > > Sent: Monday, 3 February, 2014 8:39:11 AM
> > > > > Subject: Re: [undertow-dev] serving static files
> > > > > 
> > > > > HEllo,
> > > > > 
> > > > > that works fine - however trying the same in my 'test': does not work
> > > > > :-/
> > > > > 
> > > > > 
> > > > >         UndertowJaxrsServer ut = new UndertowJaxrsServer();
> > > > > 
> > > > >         TestApplication ta = new TestApplication();
> > > > > 
> > > > >         ut.deploy(ta);
> > > > > 
> > > > >         ut.start(
> > > > >                 Undertow.builder()
> > > > >                         .addHttpListener(8080, "localhost")
> > > > >                         .setHandler(resource(new
> > > > >                         FileResourceManager(new
> > > > >                         File(System.getProperty("user.home")), 100))
> > > > >                                 .setDirectoryListingEnabled(true))
> > > > > 
> > > > > 
> > > > >         );
> > > > > 
> > > > >         try {
> > > > >             Thread.currentThread().join();
> > > > >         }
> > > > >         catch (InterruptedException e) {
> > > > >             logger.info("shutting down");
> > > > >             ut.stop();
> > > > >         }
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > -Matthias
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > Cc: undertow-dev at lists.jboss.org
> > > > > > Sent: Sunday, February 2, 2014 6:37:59 PM
> > > > > > Subject: Re: [undertow-dev] serving static files
> > > > > > 
> > > > > > I just added a file serving example to the Undertow examples, can
> > > > > > you
> > > > > > try
> > > > > > that out and let me know if it works for you?
> > > > > > 
> > > > > > Just get the latest Undertow, build the examples, then run:
> > > > > > 
> > > > > > mvn exec:exec
> > > > > > 
> > > > > > And select the file serving one, it should serve up you home
> > > > > > directory.
> > > > > > 
> > > > > > Stuart
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > > To: undertow-dev at lists.jboss.org
> > > > > > > Sent: Sunday, 2 February, 2014 1:58:14 PM
> > > > > > > Subject: [undertow-dev] serving static files
> > > > > > > 
> > > > > > > Hello,
> > > > > > > 
> > > > > > > I might be just doing it wrong, but the following attempts are
> > > > > > > not
> > > > > > > successful
> > > > > > > for serving static files from a folder:
> > > > > > > 
> > > > > > > 
> > > > > > >         UndertowJaxrsServer ut = new UndertowJaxrsServer();
> > > > > > >  
> > > > > > >         MyRestApplication app = new MyRestApplication();
> > > > > > >  
> > > > > > >         ut.deploy(app);
> > > > > > >  
> > > > > > >         ut.start(
> > > > > > >                 Undertow.builder()
> > > > > > >                         .addHttpListener(8080, "0.0.0.0")
> > > > > > > 
> > > > > > >  
> > > > > > >                 // first tried this:
> > > > > > >                         .setHandler(path()
> > > > > > >                                     .addPrefixPath("/",resource(new
> > > > > > >                                     FileResourceManager(new
> > > > > > >                                     File("/some/folder/containing/html/files"),
> > > > > > >                                     1024))))
> > > > > > >  
> > > > > > > 
> > > > > > >                 // afterwards also tried this:
> > > > > > >                         .setHandler(resource(new
> > > > > > >                         FileResourceManager(new
> > > > > > >                         File("/some/folder/containing/html/files"),
> > > > > > >                         1024)))
> > > > > > >         );
> > > > > > >  
> > > > > > >         try {
> > > > > > >             Thread.currentThread().join();
> > > > > > >         }
> > > > > > >         catch (InterruptedException e) {
> > > > > > >             logger.info("shutting down");
> > > > > > >             ut.stop();
> > > > > > >         }
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Not sure, but none of the above handlers seems to server files
> > > > > > > from
> > > > > > > a
> > > > > > > folder
> > > > > > > on my box
> > > > > > > 
> > > > > > > 
> > > > > > > Greetings,
> > > > > > > Matthias
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > --
> > > > > > > Matthias Wessendorf
> > > > > > > matzew at redhat.com
> > > > > > > 
> > > > > > > JBoss, by Red Hat
> > > > > > > _______________________________________________
> > > > > > > undertow-dev mailing list
> > > > > > > undertow-dev at lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > > > > > > 
> > > > > > 
> > > > > 
> > > > > --
> > > > > Matthias Wessendorf
> > > > > matzew at redhat.com
> > > > > 
> > > > > JBoss, by Red Hat
> > > > > 
> > > > 
> > > 
> > > --
> > > Matthias Wessendorf
> > > matzew at redhat.com
> > > 
> > > JBoss, by Red Hat
> > > 
> > 
> 
> --
> Matthias Wessendorf
> matzew at redhat.com
> 
> JBoss, by Red Hat
> 

From matzew at redhat.com  Mon Feb  3 05:24:23 2014
From: matzew at redhat.com (Matthias Wessendorf)
Date: Mon, 3 Feb 2014 05:24:23 -0500 (EST)
Subject: [undertow-dev] serving static files
In-Reply-To: <1678388693.10020906.1391418976723.JavaMail.root@redhat.com>
References: <1971447378.17406083.1391342294137.JavaMail.root@redhat.com>
	<730639716.9940460.1391362679920.JavaMail.root@redhat.com>
	<537948257.17560402.1391409551725.JavaMail.root@redhat.com>
	<1200023593.10003438.1391413148352.JavaMail.root@redhat.com>
	<709822249.17604936.1391416684157.JavaMail.root@redhat.com>
	<1505628887.10018293.1391417862661.JavaMail.root@redhat.com>
	<454257937.17620291.1391418750370.JavaMail.root@redhat.com>
	<1678388693.10020906.1391418976723.JavaMail.root@redhat.com>
Message-ID: <266330747.17652958.1391423063902.JavaMail.root@redhat.com>

Thanks for the reply,

using the Extension works very well - updated my example project:

https://github.com/matzew/undertow-jaxrs-test/blob/master/src/main/resources/META-INF/services/io.undertow.servlet.ServletExtension

-M

----- Original Message -----
> From: "Stuart Douglas" <sdouglas at redhat.com>
> To: "Matthias Wessendorf" <matzew at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Monday, February 3, 2014 10:16:16 AM
> Subject: Re: [undertow-dev] serving static files
> 
> Yes and no.
> 
> It looks like Bill has not added that capability into the Resteasy server,
> however you could use a ServletExtension to serve static files from certain
> paths:
> 
> http://undertow.io/documentation/servlet/using-non-blocking-handlers-with-servlet.html
> 
> The other option would be to file a Resteasy JIRA (or better yet provide a
> pull request) to add more flexibility to the server.
> 
> Stuart
> 
> ----- Original Message -----
> > From: "Matthias Wessendorf" <matzew at redhat.com>
> > To: "Stuart Douglas" <sdouglas at redhat.com>
> > Cc: undertow-dev at lists.jboss.org
> > Sent: Monday, 3 February, 2014 11:12:30 AM
> > Subject: Re: [undertow-dev] serving static files
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > Cc: undertow-dev at lists.jboss.org
> > > Sent: Monday, February 3, 2014 9:57:42 AM
> > > Subject: Re: [undertow-dev] serving static files
> > > 
> > > This is the code from the Resteasy Undertow server:
> > > 
> > >    public UndertowJaxrsServer start(Undertow.Builder builder)
> > >    {
> > >       server = builder.setHandler(root).build();
> > >       server.start();
> > >       return this;
> > >    }
> > > 
> > > So basically when you call start the servlet container is always
> > > registered
> > > as the root resource.
> > 
> > So, that means I am not able to provide a 'FileResourceManager' in that
> > Undertow/RestEasy combination ?
> > 
> > > 
> > > 
> > > Stuart
> > > 
> > > ----- Original Message -----
> > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > To: "Stuart Douglas" <sdouglas at redhat.com>
> > > > Cc: undertow-dev at lists.jboss.org
> > > > Sent: Monday, 3 February, 2014 10:38:04 AM
> > > > Subject: Re: [undertow-dev] serving static files
> > > > 
> > > > Hello Stuart,
> > > > 
> > > > I pushed my test to github. the 'main' is located here:
> > > > https://github.com/matzew/undertow-jaxrs-test/blob/master/src/main/java/net/wessendorf/undertow/App.java
> > > > 
> > > > When I run that and I am accessing "http://localhost:8080/status", all
> > > > is
> > > > fine, my 'StatusEndpoint' JAX-RS resource is executed and I get my
> > > > response;
> > > > However, when I am hitting "http://localhost:8080" am getting 404 in
> > > > the
> > > > browser, and the following on the console in my IDE:
> > > > 
> > > > 
> > > > Feb 03, 2014 9:26:04 AM org.jboss.resteasy.core.ExceptionHandler
> > > > SEVERE: failed to execute
> > > > javax.ws.rs.NotFoundException: Could not find resource for full path:
> > > > http://localhost:8080/
> > > > 	at org.jboss.resteasy.core.registry.ClassNode.match(ClassNode.java:73)
> > > > 	at
> > > > 	org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48)
> > > > 	at
> > > > 	org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:444)
> > > > 	at
> > > > 	org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:234)
> > > > 	at
> > > > 	org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:171)
> > > > 	at
> > > > 	org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> > > > 	at
> > > > 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> > > > 	at
> > > > 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> > > > 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> > > > 	at
> > > > 	io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> > > > 	at
> > > > 	io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> > > > 	at
> > > > 	io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> > > > 	at
> > > > 	io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> > > > 	at
> > > > 	io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> > > > 	at
> > > > 	io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> > > > 	at
> > > > 	io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> > > > 	at
> > > > 	io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> > > > 	at
> > > > 	io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> > > > 	at
> > > > 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > > > 	at
> > > > 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > > > 	at
> > > > 	io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
> > > > 	at
> > > > 	io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> > > > 	at
> > > > 	io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> > > > 	at
> > > > 	io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> > > > 	at
> > > > 	io.undertow.server.Connectors.executeRootHandler(Connectors.java:168)
> > > > 	at
> > > > 	io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
> > > > 	at
> > > > 	java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> > > > 	at
> > > > 	java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> > > > 	at java.lang.Thread.run(Thread.java:722)
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > So, looks like the JAX-RS is somewhat having an effect on the actual
> > > > "FileResourceManager" that should serve my static files
> > > > 
> > > > 
> > > > 
> > > > -Matthias
> > > > 
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > Cc: undertow-dev at lists.jboss.org
> > > > > Sent: Monday, February 3, 2014 8:39:08 AM
> > > > > Subject: Re: [undertow-dev] serving static files
> > > > > 
> > > > > What does the rest of your code look like? And when you say it does
> > > > > not
> > > > > work,
> > > > > what sort of failure are you getting? A 404?
> > > > > 
> > > > > Stuart
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > To: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > > Cc: undertow-dev at lists.jboss.org
> > > > > > Sent: Monday, 3 February, 2014 8:39:11 AM
> > > > > > Subject: Re: [undertow-dev] serving static files
> > > > > > 
> > > > > > HEllo,
> > > > > > 
> > > > > > that works fine - however trying the same in my 'test': does not
> > > > > > work
> > > > > > :-/
> > > > > > 
> > > > > > 
> > > > > >         UndertowJaxrsServer ut = new UndertowJaxrsServer();
> > > > > > 
> > > > > >         TestApplication ta = new TestApplication();
> > > > > > 
> > > > > >         ut.deploy(ta);
> > > > > > 
> > > > > >         ut.start(
> > > > > >                 Undertow.builder()
> > > > > >                         .addHttpListener(8080, "localhost")
> > > > > >                         .setHandler(resource(new
> > > > > >                         FileResourceManager(new
> > > > > >                         File(System.getProperty("user.home")),
> > > > > >                         100))
> > > > > >                                 .setDirectoryListingEnabled(true))
> > > > > > 
> > > > > > 
> > > > > >         );
> > > > > > 
> > > > > >         try {
> > > > > >             Thread.currentThread().join();
> > > > > >         }
> > > > > >         catch (InterruptedException e) {
> > > > > >             logger.info("shutting down");
> > > > > >             ut.stop();
> > > > > >         }
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > -Matthias
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > > Cc: undertow-dev at lists.jboss.org
> > > > > > > Sent: Sunday, February 2, 2014 6:37:59 PM
> > > > > > > Subject: Re: [undertow-dev] serving static files
> > > > > > > 
> > > > > > > I just added a file serving example to the Undertow examples, can
> > > > > > > you
> > > > > > > try
> > > > > > > that out and let me know if it works for you?
> > > > > > > 
> > > > > > > Just get the latest Undertow, build the examples, then run:
> > > > > > > 
> > > > > > > mvn exec:exec
> > > > > > > 
> > > > > > > And select the file serving one, it should serve up you home
> > > > > > > directory.
> > > > > > > 
> > > > > > > Stuart
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > > > To: undertow-dev at lists.jboss.org
> > > > > > > > Sent: Sunday, 2 February, 2014 1:58:14 PM
> > > > > > > > Subject: [undertow-dev] serving static files
> > > > > > > > 
> > > > > > > > Hello,
> > > > > > > > 
> > > > > > > > I might be just doing it wrong, but the following attempts are
> > > > > > > > not
> > > > > > > > successful
> > > > > > > > for serving static files from a folder:
> > > > > > > > 
> > > > > > > > 
> > > > > > > >         UndertowJaxrsServer ut = new UndertowJaxrsServer();
> > > > > > > >  
> > > > > > > >         MyRestApplication app = new MyRestApplication();
> > > > > > > >  
> > > > > > > >         ut.deploy(app);
> > > > > > > >  
> > > > > > > >         ut.start(
> > > > > > > >                 Undertow.builder()
> > > > > > > >                         .addHttpListener(8080, "0.0.0.0")
> > > > > > > > 
> > > > > > > >  
> > > > > > > >                 // first tried this:
> > > > > > > >                         .setHandler(path()
> > > > > > > >                                     .addPrefixPath("/",resource(new
> > > > > > > >                                     FileResourceManager(new
> > > > > > > >                                     File("/some/folder/containing/html/files"),
> > > > > > > >                                     1024))))
> > > > > > > >  
> > > > > > > > 
> > > > > > > >                 // afterwards also tried this:
> > > > > > > >                         .setHandler(resource(new
> > > > > > > >                         FileResourceManager(new
> > > > > > > >                         File("/some/folder/containing/html/files"),
> > > > > > > >                         1024)))
> > > > > > > >         );
> > > > > > > >  
> > > > > > > >         try {
> > > > > > > >             Thread.currentThread().join();
> > > > > > > >         }
> > > > > > > >         catch (InterruptedException e) {
> > > > > > > >             logger.info("shutting down");
> > > > > > > >             ut.stop();
> > > > > > > >         }
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Not sure, but none of the above handlers seems to server files
> > > > > > > > from
> > > > > > > > a
> > > > > > > > folder
> > > > > > > > on my box
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Greetings,
> > > > > > > > Matthias
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > --
> > > > > > > > Matthias Wessendorf
> > > > > > > > matzew at redhat.com
> > > > > > > > 
> > > > > > > > JBoss, by Red Hat
> > > > > > > > _______________________________________________
> > > > > > > > undertow-dev mailing list
> > > > > > > > undertow-dev at lists.jboss.org
> > > > > > > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > --
> > > > > > Matthias Wessendorf
> > > > > > matzew at redhat.com
> > > > > > 
> > > > > > JBoss, by Red Hat
> > > > > > 
> > > > > 
> > > > 
> > > > --
> > > > Matthias Wessendorf
> > > > matzew at redhat.com
> > > > 
> > > > JBoss, by Red Hat
> > > > 
> > > 
> > 
> > --
> > Matthias Wessendorf
> > matzew at redhat.com
> > 
> > JBoss, by Red Hat
> > 
> 

-- 
Matthias Wessendorf
matzew at redhat.com

JBoss, by Red Hat

From matzew at redhat.com  Mon Feb  3 05:29:56 2014
From: matzew at redhat.com (Matthias Wessendorf)
Date: Mon, 3 Feb 2014 05:29:56 -0500 (EST)
Subject: [undertow-dev] serving static files
In-Reply-To: <266330747.17652958.1391423063902.JavaMail.root@redhat.com>
References: <1971447378.17406083.1391342294137.JavaMail.root@redhat.com>
	<537948257.17560402.1391409551725.JavaMail.root@redhat.com>
	<1200023593.10003438.1391413148352.JavaMail.root@redhat.com>
	<709822249.17604936.1391416684157.JavaMail.root@redhat.com>
	<1505628887.10018293.1391417862661.JavaMail.root@redhat.com>
	<454257937.17620291.1391418750370.JavaMail.root@redhat.com>
	<1678388693.10020906.1391418976723.JavaMail.root@redhat.com>
	<266330747.17652958.1391423063902.JavaMail.root@redhat.com>
Message-ID: <1892702291.17656605.1391423396370.JavaMail.root@redhat.com>

But now the JAX-RS endpoint no longer works :)



----- Original Message -----
> From: "Matthias Wessendorf" <matzew at redhat.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Monday, February 3, 2014 11:24:23 AM
> Subject: Re: [undertow-dev] serving static files
> 
> Thanks for the reply,
> 
> using the Extension works very well - updated my example project:
> 
> https://github.com/matzew/undertow-jaxrs-test/blob/master/src/main/resources/META-INF/services/io.undertow.servlet.ServletExtension
> 
> -M
> 
> ----- Original Message -----
> > From: "Stuart Douglas" <sdouglas at redhat.com>
> > To: "Matthias Wessendorf" <matzew at redhat.com>
> > Cc: undertow-dev at lists.jboss.org
> > Sent: Monday, February 3, 2014 10:16:16 AM
> > Subject: Re: [undertow-dev] serving static files
> > 
> > Yes and no.
> > 
> > It looks like Bill has not added that capability into the Resteasy server,
> > however you could use a ServletExtension to serve static files from certain
> > paths:
> > 
> > http://undertow.io/documentation/servlet/using-non-blocking-handlers-with-servlet.html
> > 
> > The other option would be to file a Resteasy JIRA (or better yet provide a
> > pull request) to add more flexibility to the server.
> > 
> > Stuart
> > 
> > ----- Original Message -----
> > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > To: "Stuart Douglas" <sdouglas at redhat.com>
> > > Cc: undertow-dev at lists.jboss.org
> > > Sent: Monday, 3 February, 2014 11:12:30 AM
> > > Subject: Re: [undertow-dev] serving static files
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > > Cc: undertow-dev at lists.jboss.org
> > > > Sent: Monday, February 3, 2014 9:57:42 AM
> > > > Subject: Re: [undertow-dev] serving static files
> > > > 
> > > > This is the code from the Resteasy Undertow server:
> > > > 
> > > >    public UndertowJaxrsServer start(Undertow.Builder builder)
> > > >    {
> > > >       server = builder.setHandler(root).build();
> > > >       server.start();
> > > >       return this;
> > > >    }
> > > > 
> > > > So basically when you call start the servlet container is always
> > > > registered
> > > > as the root resource.
> > > 
> > > So, that means I am not able to provide a 'FileResourceManager' in that
> > > Undertow/RestEasy combination ?
> > > 
> > > > 
> > > > 
> > > > Stuart
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > To: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > Cc: undertow-dev at lists.jboss.org
> > > > > Sent: Monday, 3 February, 2014 10:38:04 AM
> > > > > Subject: Re: [undertow-dev] serving static files
> > > > > 
> > > > > Hello Stuart,
> > > > > 
> > > > > I pushed my test to github. the 'main' is located here:
> > > > > https://github.com/matzew/undertow-jaxrs-test/blob/master/src/main/java/net/wessendorf/undertow/App.java
> > > > > 
> > > > > When I run that and I am accessing "http://localhost:8080/status",
> > > > > all
> > > > > is
> > > > > fine, my 'StatusEndpoint' JAX-RS resource is executed and I get my
> > > > > response;
> > > > > However, when I am hitting "http://localhost:8080" am getting 404 in
> > > > > the
> > > > > browser, and the following on the console in my IDE:
> > > > > 
> > > > > 
> > > > > Feb 03, 2014 9:26:04 AM org.jboss.resteasy.core.ExceptionHandler
> > > > > SEVERE: failed to execute
> > > > > javax.ws.rs.NotFoundException: Could not find resource for full path:
> > > > > http://localhost:8080/
> > > > > 	at
> > > > > 	org.jboss.resteasy.core.registry.ClassNode.match(ClassNode.java:73)
> > > > > 	at
> > > > > 	org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48)
> > > > > 	at
> > > > > 	org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:444)
> > > > > 	at
> > > > > 	org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:234)
> > > > > 	at
> > > > > 	org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:171)
> > > > > 	at
> > > > > 	org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> > > > > 	at
> > > > > 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> > > > > 	at
> > > > > 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> > > > > 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> > > > > 	at
> > > > > 	io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> > > > > 	at
> > > > > 	io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> > > > > 	at
> > > > > 	io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> > > > > 	at
> > > > > 	io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> > > > > 	at
> > > > > 	io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> > > > > 	at
> > > > > 	io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> > > > > 	at
> > > > > 	io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> > > > > 	at
> > > > > 	io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> > > > > 	at
> > > > > 	io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> > > > > 	at
> > > > > 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > > > > 	at
> > > > > 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > > > > 	at
> > > > > 	io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
> > > > > 	at
> > > > > 	io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> > > > > 	at
> > > > > 	io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> > > > > 	at
> > > > > 	io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> > > > > 	at
> > > > > 	io.undertow.server.Connectors.executeRootHandler(Connectors.java:168)
> > > > > 	at
> > > > > 	io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
> > > > > 	at
> > > > > 	java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> > > > > 	at
> > > > > 	java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> > > > > 	at java.lang.Thread.run(Thread.java:722)
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > So, looks like the JAX-RS is somewhat having an effect on the actual
> > > > > "FileResourceManager" that should serve my static files
> > > > > 
> > > > > 
> > > > > 
> > > > > -Matthias
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > Cc: undertow-dev at lists.jboss.org
> > > > > > Sent: Monday, February 3, 2014 8:39:08 AM
> > > > > > Subject: Re: [undertow-dev] serving static files
> > > > > > 
> > > > > > What does the rest of your code look like? And when you say it does
> > > > > > not
> > > > > > work,
> > > > > > what sort of failure are you getting? A 404?
> > > > > > 
> > > > > > Stuart
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > > To: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > > > Cc: undertow-dev at lists.jboss.org
> > > > > > > Sent: Monday, 3 February, 2014 8:39:11 AM
> > > > > > > Subject: Re: [undertow-dev] serving static files
> > > > > > > 
> > > > > > > HEllo,
> > > > > > > 
> > > > > > > that works fine - however trying the same in my 'test': does not
> > > > > > > work
> > > > > > > :-/
> > > > > > > 
> > > > > > > 
> > > > > > >         UndertowJaxrsServer ut = new UndertowJaxrsServer();
> > > > > > > 
> > > > > > >         TestApplication ta = new TestApplication();
> > > > > > > 
> > > > > > >         ut.deploy(ta);
> > > > > > > 
> > > > > > >         ut.start(
> > > > > > >                 Undertow.builder()
> > > > > > >                         .addHttpListener(8080, "localhost")
> > > > > > >                         .setHandler(resource(new
> > > > > > >                         FileResourceManager(new
> > > > > > >                         File(System.getProperty("user.home")),
> > > > > > >                         100))
> > > > > > >                                 .setDirectoryListingEnabled(true))
> > > > > > > 
> > > > > > > 
> > > > > > >         );
> > > > > > > 
> > > > > > >         try {
> > > > > > >             Thread.currentThread().join();
> > > > > > >         }
> > > > > > >         catch (InterruptedException e) {
> > > > > > >             logger.info("shutting down");
> > > > > > >             ut.stop();
> > > > > > >         }
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > -Matthias
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > > > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > > > Cc: undertow-dev at lists.jboss.org
> > > > > > > > Sent: Sunday, February 2, 2014 6:37:59 PM
> > > > > > > > Subject: Re: [undertow-dev] serving static files
> > > > > > > > 
> > > > > > > > I just added a file serving example to the Undertow examples,
> > > > > > > > can
> > > > > > > > you
> > > > > > > > try
> > > > > > > > that out and let me know if it works for you?
> > > > > > > > 
> > > > > > > > Just get the latest Undertow, build the examples, then run:
> > > > > > > > 
> > > > > > > > mvn exec:exec
> > > > > > > > 
> > > > > > > > And select the file serving one, it should serve up you home
> > > > > > > > directory.
> > > > > > > > 
> > > > > > > > Stuart
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > > > > To: undertow-dev at lists.jboss.org
> > > > > > > > > Sent: Sunday, 2 February, 2014 1:58:14 PM
> > > > > > > > > Subject: [undertow-dev] serving static files
> > > > > > > > > 
> > > > > > > > > Hello,
> > > > > > > > > 
> > > > > > > > > I might be just doing it wrong, but the following attempts
> > > > > > > > > are
> > > > > > > > > not
> > > > > > > > > successful
> > > > > > > > > for serving static files from a folder:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > >         UndertowJaxrsServer ut = new UndertowJaxrsServer();
> > > > > > > > >  
> > > > > > > > >         MyRestApplication app = new MyRestApplication();
> > > > > > > > >  
> > > > > > > > >         ut.deploy(app);
> > > > > > > > >  
> > > > > > > > >         ut.start(
> > > > > > > > >                 Undertow.builder()
> > > > > > > > >                         .addHttpListener(8080, "0.0.0.0")
> > > > > > > > > 
> > > > > > > > >  
> > > > > > > > >                 // first tried this:
> > > > > > > > >                         .setHandler(path()
> > > > > > > > >                                     .addPrefixPath("/",resource(new
> > > > > > > > >                                     FileResourceManager(new
> > > > > > > > >                                     File("/some/folder/containing/html/files"),
> > > > > > > > >                                     1024))))
> > > > > > > > >  
> > > > > > > > > 
> > > > > > > > >                 // afterwards also tried this:
> > > > > > > > >                         .setHandler(resource(new
> > > > > > > > >                         FileResourceManager(new
> > > > > > > > >                         File("/some/folder/containing/html/files"),
> > > > > > > > >                         1024)))
> > > > > > > > >         );
> > > > > > > > >  
> > > > > > > > >         try {
> > > > > > > > >             Thread.currentThread().join();
> > > > > > > > >         }
> > > > > > > > >         catch (InterruptedException e) {
> > > > > > > > >             logger.info("shutting down");
> > > > > > > > >             ut.stop();
> > > > > > > > >         }
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Not sure, but none of the above handlers seems to server
> > > > > > > > > files
> > > > > > > > > from
> > > > > > > > > a
> > > > > > > > > folder
> > > > > > > > > on my box
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Greetings,
> > > > > > > > > Matthias
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > --
> > > > > > > > > Matthias Wessendorf
> > > > > > > > > matzew at redhat.com
> > > > > > > > > 
> > > > > > > > > JBoss, by Red Hat
> > > > > > > > > _______________________________________________
> > > > > > > > > undertow-dev mailing list
> > > > > > > > > undertow-dev at lists.jboss.org
> > > > > > > > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > > --
> > > > > > > Matthias Wessendorf
> > > > > > > matzew at redhat.com
> > > > > > > 
> > > > > > > JBoss, by Red Hat
> > > > > > > 
> > > > > > 
> > > > > 
> > > > > --
> > > > > Matthias Wessendorf
> > > > > matzew at redhat.com
> > > > > 
> > > > > JBoss, by Red Hat
> > > > > 
> > > > 
> > > 
> > > --
> > > Matthias Wessendorf
> > > matzew at redhat.com
> > > 
> > > JBoss, by Red Hat
> > > 
> > 
> 
> --
> Matthias Wessendorf
> matzew at redhat.com
> 
> JBoss, by Red Hat
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

-- 
Matthias Wessendorf
matzew at redhat.com

JBoss, by Red Hat

From sdouglas at redhat.com  Mon Feb  3 05:38:06 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 3 Feb 2014 05:38:06 -0500 (EST)
Subject: [undertow-dev] serving static files
In-Reply-To: <1892702291.17656605.1391423396370.JavaMail.root@redhat.com>
References: <1971447378.17406083.1391342294137.JavaMail.root@redhat.com>
	<1200023593.10003438.1391413148352.JavaMail.root@redhat.com>
	<709822249.17604936.1391416684157.JavaMail.root@redhat.com>
	<1505628887.10018293.1391417862661.JavaMail.root@redhat.com>
	<454257937.17620291.1391418750370.JavaMail.root@redhat.com>
	<1678388693.10020906.1391418976723.JavaMail.root@redhat.com>
	<266330747.17652958.1391423063902.JavaMail.root@redhat.com>
	<1892702291.17656605.1391423396370.JavaMail.root@redhat.com>
Message-ID: <1336138035.10049518.1391423886523.JavaMail.root@redhat.com>

You need to make a choice in the handler when to delegate to the next handler (i.e. servlet), and when to intercept the request and serve your static files. 

Generally you will do this by simply looking at the path. If for example you only want to serve some paths from JAX-RS you can use a path prefix predicate to specify the paths that get delegated to the servlet handler, and hand everything else to your resource handler. 

Note that this is all a bit of a hack, the correct way to do this would be to modify the resteasy server so it does not register itself as the root handler.

Stuart

----- Original Message -----
> From: "Matthias Wessendorf" <matzew at redhat.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Monday, 3 February, 2014 12:29:56 PM
> Subject: Re: [undertow-dev] serving static files
> 
> But now the JAX-RS endpoint no longer works :)
> 
> 
> 
> ----- Original Message -----
> > From: "Matthias Wessendorf" <matzew at redhat.com>
> > To: "Stuart Douglas" <sdouglas at redhat.com>
> > Cc: undertow-dev at lists.jboss.org
> > Sent: Monday, February 3, 2014 11:24:23 AM
> > Subject: Re: [undertow-dev] serving static files
> > 
> > Thanks for the reply,
> > 
> > using the Extension works very well - updated my example project:
> > 
> > https://github.com/matzew/undertow-jaxrs-test/blob/master/src/main/resources/META-INF/services/io.undertow.servlet.ServletExtension
> > 
> > -M
> > 
> > ----- Original Message -----
> > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > Cc: undertow-dev at lists.jboss.org
> > > Sent: Monday, February 3, 2014 10:16:16 AM
> > > Subject: Re: [undertow-dev] serving static files
> > > 
> > > Yes and no.
> > > 
> > > It looks like Bill has not added that capability into the Resteasy
> > > server,
> > > however you could use a ServletExtension to serve static files from
> > > certain
> > > paths:
> > > 
> > > http://undertow.io/documentation/servlet/using-non-blocking-handlers-with-servlet.html
> > > 
> > > The other option would be to file a Resteasy JIRA (or better yet provide
> > > a
> > > pull request) to add more flexibility to the server.
> > > 
> > > Stuart
> > > 
> > > ----- Original Message -----
> > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > To: "Stuart Douglas" <sdouglas at redhat.com>
> > > > Cc: undertow-dev at lists.jboss.org
> > > > Sent: Monday, 3 February, 2014 11:12:30 AM
> > > > Subject: Re: [undertow-dev] serving static files
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > Cc: undertow-dev at lists.jboss.org
> > > > > Sent: Monday, February 3, 2014 9:57:42 AM
> > > > > Subject: Re: [undertow-dev] serving static files
> > > > > 
> > > > > This is the code from the Resteasy Undertow server:
> > > > > 
> > > > >    public UndertowJaxrsServer start(Undertow.Builder builder)
> > > > >    {
> > > > >       server = builder.setHandler(root).build();
> > > > >       server.start();
> > > > >       return this;
> > > > >    }
> > > > > 
> > > > > So basically when you call start the servlet container is always
> > > > > registered
> > > > > as the root resource.
> > > > 
> > > > So, that means I am not able to provide a 'FileResourceManager' in that
> > > > Undertow/RestEasy combination ?
> > > > 
> > > > > 
> > > > > 
> > > > > Stuart
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > To: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > > Cc: undertow-dev at lists.jboss.org
> > > > > > Sent: Monday, 3 February, 2014 10:38:04 AM
> > > > > > Subject: Re: [undertow-dev] serving static files
> > > > > > 
> > > > > > Hello Stuart,
> > > > > > 
> > > > > > I pushed my test to github. the 'main' is located here:
> > > > > > https://github.com/matzew/undertow-jaxrs-test/blob/master/src/main/java/net/wessendorf/undertow/App.java
> > > > > > 
> > > > > > When I run that and I am accessing "http://localhost:8080/status",
> > > > > > all
> > > > > > is
> > > > > > fine, my 'StatusEndpoint' JAX-RS resource is executed and I get my
> > > > > > response;
> > > > > > However, when I am hitting "http://localhost:8080" am getting 404
> > > > > > in
> > > > > > the
> > > > > > browser, and the following on the console in my IDE:
> > > > > > 
> > > > > > 
> > > > > > Feb 03, 2014 9:26:04 AM org.jboss.resteasy.core.ExceptionHandler
> > > > > > SEVERE: failed to execute
> > > > > > javax.ws.rs.NotFoundException: Could not find resource for full
> > > > > > path:
> > > > > > http://localhost:8080/
> > > > > > 	at
> > > > > > 	org.jboss.resteasy.core.registry.ClassNode.match(ClassNode.java:73)
> > > > > > 	at
> > > > > > 	org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48)
> > > > > > 	at
> > > > > > 	org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:444)
> > > > > > 	at
> > > > > > 	org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:234)
> > > > > > 	at
> > > > > > 	org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:171)
> > > > > > 	at
> > > > > > 	org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> > > > > > 	at
> > > > > > 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> > > > > > 	at
> > > > > > 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> > > > > > 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> > > > > > 	at
> > > > > > 	io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> > > > > > 	at
> > > > > > 	io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> > > > > > 	at
> > > > > > 	io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> > > > > > 	at
> > > > > > 	io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> > > > > > 	at
> > > > > > 	io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> > > > > > 	at
> > > > > > 	io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> > > > > > 	at
> > > > > > 	io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> > > > > > 	at
> > > > > > 	io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> > > > > > 	at
> > > > > > 	io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> > > > > > 	at
> > > > > > 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > > > > > 	at
> > > > > > 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > > > > > 	at
> > > > > > 	io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
> > > > > > 	at
> > > > > > 	io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> > > > > > 	at
> > > > > > 	io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> > > > > > 	at
> > > > > > 	io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> > > > > > 	at
> > > > > > 	io.undertow.server.Connectors.executeRootHandler(Connectors.java:168)
> > > > > > 	at
> > > > > > 	io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
> > > > > > 	at
> > > > > > 	java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> > > > > > 	at
> > > > > > 	java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> > > > > > 	at java.lang.Thread.run(Thread.java:722)
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > So, looks like the JAX-RS is somewhat having an effect on the
> > > > > > actual
> > > > > > "FileResourceManager" that should serve my static files
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > -Matthias
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > > Cc: undertow-dev at lists.jboss.org
> > > > > > > Sent: Monday, February 3, 2014 8:39:08 AM
> > > > > > > Subject: Re: [undertow-dev] serving static files
> > > > > > > 
> > > > > > > What does the rest of your code look like? And when you say it
> > > > > > > does
> > > > > > > not
> > > > > > > work,
> > > > > > > what sort of failure are you getting? A 404?
> > > > > > > 
> > > > > > > Stuart
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > > > To: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > > > > Cc: undertow-dev at lists.jboss.org
> > > > > > > > Sent: Monday, 3 February, 2014 8:39:11 AM
> > > > > > > > Subject: Re: [undertow-dev] serving static files
> > > > > > > > 
> > > > > > > > HEllo,
> > > > > > > > 
> > > > > > > > that works fine - however trying the same in my 'test': does
> > > > > > > > not
> > > > > > > > work
> > > > > > > > :-/
> > > > > > > > 
> > > > > > > > 
> > > > > > > >         UndertowJaxrsServer ut = new UndertowJaxrsServer();
> > > > > > > > 
> > > > > > > >         TestApplication ta = new TestApplication();
> > > > > > > > 
> > > > > > > >         ut.deploy(ta);
> > > > > > > > 
> > > > > > > >         ut.start(
> > > > > > > >                 Undertow.builder()
> > > > > > > >                         .addHttpListener(8080, "localhost")
> > > > > > > >                         .setHandler(resource(new
> > > > > > > >                         FileResourceManager(new
> > > > > > > >                         File(System.getProperty("user.home")),
> > > > > > > >                         100))
> > > > > > > >                                 .setDirectoryListingEnabled(true))
> > > > > > > > 
> > > > > > > > 
> > > > > > > >         );
> > > > > > > > 
> > > > > > > >         try {
> > > > > > > >             Thread.currentThread().join();
> > > > > > > >         }
> > > > > > > >         catch (InterruptedException e) {
> > > > > > > >             logger.info("shutting down");
> > > > > > > >             ut.stop();
> > > > > > > >         }
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > -Matthias
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > > > > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > > > > Cc: undertow-dev at lists.jboss.org
> > > > > > > > > Sent: Sunday, February 2, 2014 6:37:59 PM
> > > > > > > > > Subject: Re: [undertow-dev] serving static files
> > > > > > > > > 
> > > > > > > > > I just added a file serving example to the Undertow examples,
> > > > > > > > > can
> > > > > > > > > you
> > > > > > > > > try
> > > > > > > > > that out and let me know if it works for you?
> > > > > > > > > 
> > > > > > > > > Just get the latest Undertow, build the examples, then run:
> > > > > > > > > 
> > > > > > > > > mvn exec:exec
> > > > > > > > > 
> > > > > > > > > And select the file serving one, it should serve up you home
> > > > > > > > > directory.
> > > > > > > > > 
> > > > > > > > > Stuart
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > > > > > To: undertow-dev at lists.jboss.org
> > > > > > > > > > Sent: Sunday, 2 February, 2014 1:58:14 PM
> > > > > > > > > > Subject: [undertow-dev] serving static files
> > > > > > > > > > 
> > > > > > > > > > Hello,
> > > > > > > > > > 
> > > > > > > > > > I might be just doing it wrong, but the following attempts
> > > > > > > > > > are
> > > > > > > > > > not
> > > > > > > > > > successful
> > > > > > > > > > for serving static files from a folder:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > >         UndertowJaxrsServer ut = new UndertowJaxrsServer();
> > > > > > > > > >  
> > > > > > > > > >         MyRestApplication app = new MyRestApplication();
> > > > > > > > > >  
> > > > > > > > > >         ut.deploy(app);
> > > > > > > > > >  
> > > > > > > > > >         ut.start(
> > > > > > > > > >                 Undertow.builder()
> > > > > > > > > >                         .addHttpListener(8080, "0.0.0.0")
> > > > > > > > > > 
> > > > > > > > > >  
> > > > > > > > > >                 // first tried this:
> > > > > > > > > >                         .setHandler(path()
> > > > > > > > > >                                     .addPrefixPath("/",resource(new
> > > > > > > > > >                                     FileResourceManager(new
> > > > > > > > > >                                     File("/some/folder/containing/html/files"),
> > > > > > > > > >                                     1024))))
> > > > > > > > > >  
> > > > > > > > > > 
> > > > > > > > > >                 // afterwards also tried this:
> > > > > > > > > >                         .setHandler(resource(new
> > > > > > > > > >                         FileResourceManager(new
> > > > > > > > > >                         File("/some/folder/containing/html/files"),
> > > > > > > > > >                         1024)))
> > > > > > > > > >         );
> > > > > > > > > >  
> > > > > > > > > >         try {
> > > > > > > > > >             Thread.currentThread().join();
> > > > > > > > > >         }
> > > > > > > > > >         catch (InterruptedException e) {
> > > > > > > > > >             logger.info("shutting down");
> > > > > > > > > >             ut.stop();
> > > > > > > > > >         }
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Not sure, but none of the above handlers seems to server
> > > > > > > > > > files
> > > > > > > > > > from
> > > > > > > > > > a
> > > > > > > > > > folder
> > > > > > > > > > on my box
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Greetings,
> > > > > > > > > > Matthias
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > --
> > > > > > > > > > Matthias Wessendorf
> > > > > > > > > > matzew at redhat.com
> > > > > > > > > > 
> > > > > > > > > > JBoss, by Red Hat
> > > > > > > > > > _______________________________________________
> > > > > > > > > > undertow-dev mailing list
> > > > > > > > > > undertow-dev at lists.jboss.org
> > > > > > > > > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > --
> > > > > > > > Matthias Wessendorf
> > > > > > > > matzew at redhat.com
> > > > > > > > 
> > > > > > > > JBoss, by Red Hat
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > --
> > > > > > Matthias Wessendorf
> > > > > > matzew at redhat.com
> > > > > > 
> > > > > > JBoss, by Red Hat
> > > > > > 
> > > > > 
> > > > 
> > > > --
> > > > Matthias Wessendorf
> > > > matzew at redhat.com
> > > > 
> > > > JBoss, by Red Hat
> > > > 
> > > 
> > 
> > --
> > Matthias Wessendorf
> > matzew at redhat.com
> > 
> > JBoss, by Red Hat
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > 
> 
> --
> Matthias Wessendorf
> matzew at redhat.com
> 
> JBoss, by Red Hat
> 

From matzew at redhat.com  Mon Feb  3 05:52:19 2014
From: matzew at redhat.com (Matthias Wessendorf)
Date: Mon, 3 Feb 2014 05:52:19 -0500 (EST)
Subject: [undertow-dev] serving static files
In-Reply-To: <1336138035.10049518.1391423886523.JavaMail.root@redhat.com>
References: <1971447378.17406083.1391342294137.JavaMail.root@redhat.com>
	<709822249.17604936.1391416684157.JavaMail.root@redhat.com>
	<1505628887.10018293.1391417862661.JavaMail.root@redhat.com>
	<454257937.17620291.1391418750370.JavaMail.root@redhat.com>
	<1678388693.10020906.1391418976723.JavaMail.root@redhat.com>
	<266330747.17652958.1391423063902.JavaMail.root@redhat.com>
	<1892702291.17656605.1391423396370.JavaMail.root@redhat.com>
	<1336138035.10049518.1391423886523.JavaMail.root@redhat.com>
Message-ID: <2116771839.17666470.1391424739215.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Stuart Douglas" <sdouglas at redhat.com>
> To: "Matthias Wessendorf" <matzew at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Monday, February 3, 2014 11:38:06 AM
> Subject: Re: [undertow-dev] serving static files
> 
> You need to make a choice in the handler when to delegate to the next handler
> (i.e. servlet), and when to intercept the request and serve your static
> files.
> 
> Generally you will do this by simply looking at the path. If for example you
> only want to serve some paths from JAX-RS you can use a path prefix
> predicate to specify the paths that get delegated to the servlet handler,
> and hand everything else to your resource handler.
> 
> Note that this is all a bit of a hack, the correct way to do this would be to
> modify the resteasy server so it does not register itself as the root
> handler.

ok, thanks for all the pointers

-M

> 
> Stuart
> 
> ----- Original Message -----
> > From: "Matthias Wessendorf" <matzew at redhat.com>
> > To: "Stuart Douglas" <sdouglas at redhat.com>
> > Cc: undertow-dev at lists.jboss.org
> > Sent: Monday, 3 February, 2014 12:29:56 PM
> > Subject: Re: [undertow-dev] serving static files
> > 
> > But now the JAX-RS endpoint no longer works :)
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > To: "Stuart Douglas" <sdouglas at redhat.com>
> > > Cc: undertow-dev at lists.jboss.org
> > > Sent: Monday, February 3, 2014 11:24:23 AM
> > > Subject: Re: [undertow-dev] serving static files
> > > 
> > > Thanks for the reply,
> > > 
> > > using the Extension works very well - updated my example project:
> > > 
> > > https://github.com/matzew/undertow-jaxrs-test/blob/master/src/main/resources/META-INF/services/io.undertow.servlet.ServletExtension
> > > 
> > > -M
> > > 
> > > ----- Original Message -----
> > > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > > Cc: undertow-dev at lists.jboss.org
> > > > Sent: Monday, February 3, 2014 10:16:16 AM
> > > > Subject: Re: [undertow-dev] serving static files
> > > > 
> > > > Yes and no.
> > > > 
> > > > It looks like Bill has not added that capability into the Resteasy
> > > > server,
> > > > however you could use a ServletExtension to serve static files from
> > > > certain
> > > > paths:
> > > > 
> > > > http://undertow.io/documentation/servlet/using-non-blocking-handlers-with-servlet.html
> > > > 
> > > > The other option would be to file a Resteasy JIRA (or better yet
> > > > provide
> > > > a
> > > > pull request) to add more flexibility to the server.
> > > > 
> > > > Stuart
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > To: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > Cc: undertow-dev at lists.jboss.org
> > > > > Sent: Monday, 3 February, 2014 11:12:30 AM
> > > > > Subject: Re: [undertow-dev] serving static files
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > Cc: undertow-dev at lists.jboss.org
> > > > > > Sent: Monday, February 3, 2014 9:57:42 AM
> > > > > > Subject: Re: [undertow-dev] serving static files
> > > > > > 
> > > > > > This is the code from the Resteasy Undertow server:
> > > > > > 
> > > > > >    public UndertowJaxrsServer start(Undertow.Builder builder)
> > > > > >    {
> > > > > >       server = builder.setHandler(root).build();
> > > > > >       server.start();
> > > > > >       return this;
> > > > > >    }
> > > > > > 
> > > > > > So basically when you call start the servlet container is always
> > > > > > registered
> > > > > > as the root resource.
> > > > > 
> > > > > So, that means I am not able to provide a 'FileResourceManager' in
> > > > > that
> > > > > Undertow/RestEasy combination ?
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > Stuart
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > > To: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > > > Cc: undertow-dev at lists.jboss.org
> > > > > > > Sent: Monday, 3 February, 2014 10:38:04 AM
> > > > > > > Subject: Re: [undertow-dev] serving static files
> > > > > > > 
> > > > > > > Hello Stuart,
> > > > > > > 
> > > > > > > I pushed my test to github. the 'main' is located here:
> > > > > > > https://github.com/matzew/undertow-jaxrs-test/blob/master/src/main/java/net/wessendorf/undertow/App.java
> > > > > > > 
> > > > > > > When I run that and I am accessing
> > > > > > > "http://localhost:8080/status",
> > > > > > > all
> > > > > > > is
> > > > > > > fine, my 'StatusEndpoint' JAX-RS resource is executed and I get
> > > > > > > my
> > > > > > > response;
> > > > > > > However, when I am hitting "http://localhost:8080" am getting 404
> > > > > > > in
> > > > > > > the
> > > > > > > browser, and the following on the console in my IDE:
> > > > > > > 
> > > > > > > 
> > > > > > > Feb 03, 2014 9:26:04 AM org.jboss.resteasy.core.ExceptionHandler
> > > > > > > SEVERE: failed to execute
> > > > > > > javax.ws.rs.NotFoundException: Could not find resource for full
> > > > > > > path:
> > > > > > > http://localhost:8080/
> > > > > > > 	at
> > > > > > > 	org.jboss.resteasy.core.registry.ClassNode.match(ClassNode.java:73)
> > > > > > > 	at
> > > > > > > 	org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48)
> > > > > > > 	at
> > > > > > > 	org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:444)
> > > > > > > 	at
> > > > > > > 	org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:234)
> > > > > > > 	at
> > > > > > > 	org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:171)
> > > > > > > 	at
> > > > > > > 	org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> > > > > > > 	at
> > > > > > > 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> > > > > > > 	at
> > > > > > > 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> > > > > > > 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> > > > > > > 	at
> > > > > > > 	io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> > > > > > > 	at
> > > > > > > 	io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> > > > > > > 	at
> > > > > > > 	io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> > > > > > > 	at
> > > > > > > 	io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> > > > > > > 	at
> > > > > > > 	io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> > > > > > > 	at
> > > > > > > 	io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> > > > > > > 	at
> > > > > > > 	io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> > > > > > > 	at
> > > > > > > 	io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> > > > > > > 	at
> > > > > > > 	io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> > > > > > > 	at
> > > > > > > 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > > > > > > 	at
> > > > > > > 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > > > > > > 	at
> > > > > > > 	io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
> > > > > > > 	at
> > > > > > > 	io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> > > > > > > 	at
> > > > > > > 	io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> > > > > > > 	at
> > > > > > > 	io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> > > > > > > 	at
> > > > > > > 	io.undertow.server.Connectors.executeRootHandler(Connectors.java:168)
> > > > > > > 	at
> > > > > > > 	io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
> > > > > > > 	at
> > > > > > > 	java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> > > > > > > 	at
> > > > > > > 	java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> > > > > > > 	at java.lang.Thread.run(Thread.java:722)
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > So, looks like the JAX-RS is somewhat having an effect on the
> > > > > > > actual
> > > > > > > "FileResourceManager" that should serve my static files
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > -Matthias
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > > > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > > > Cc: undertow-dev at lists.jboss.org
> > > > > > > > Sent: Monday, February 3, 2014 8:39:08 AM
> > > > > > > > Subject: Re: [undertow-dev] serving static files
> > > > > > > > 
> > > > > > > > What does the rest of your code look like? And when you say it
> > > > > > > > does
> > > > > > > > not
> > > > > > > > work,
> > > > > > > > what sort of failure are you getting? A 404?
> > > > > > > > 
> > > > > > > > Stuart
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > > > > To: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > > > > > Cc: undertow-dev at lists.jboss.org
> > > > > > > > > Sent: Monday, 3 February, 2014 8:39:11 AM
> > > > > > > > > Subject: Re: [undertow-dev] serving static files
> > > > > > > > > 
> > > > > > > > > HEllo,
> > > > > > > > > 
> > > > > > > > > that works fine - however trying the same in my 'test': does
> > > > > > > > > not
> > > > > > > > > work
> > > > > > > > > :-/
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > >         UndertowJaxrsServer ut = new UndertowJaxrsServer();
> > > > > > > > > 
> > > > > > > > >         TestApplication ta = new TestApplication();
> > > > > > > > > 
> > > > > > > > >         ut.deploy(ta);
> > > > > > > > > 
> > > > > > > > >         ut.start(
> > > > > > > > >                 Undertow.builder()
> > > > > > > > >                         .addHttpListener(8080, "localhost")
> > > > > > > > >                         .setHandler(resource(new
> > > > > > > > >                         FileResourceManager(new
> > > > > > > > >                         File(System.getProperty("user.home")),
> > > > > > > > >                         100))
> > > > > > > > >                                 .setDirectoryListingEnabled(true))
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > >         );
> > > > > > > > > 
> > > > > > > > >         try {
> > > > > > > > >             Thread.currentThread().join();
> > > > > > > > >         }
> > > > > > > > >         catch (InterruptedException e) {
> > > > > > > > >             logger.info("shutting down");
> > > > > > > > >             ut.stop();
> > > > > > > > >         }
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > -Matthias
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Stuart Douglas" <sdouglas at redhat.com>
> > > > > > > > > > To: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > > > > > Cc: undertow-dev at lists.jboss.org
> > > > > > > > > > Sent: Sunday, February 2, 2014 6:37:59 PM
> > > > > > > > > > Subject: Re: [undertow-dev] serving static files
> > > > > > > > > > 
> > > > > > > > > > I just added a file serving example to the Undertow
> > > > > > > > > > examples,
> > > > > > > > > > can
> > > > > > > > > > you
> > > > > > > > > > try
> > > > > > > > > > that out and let me know if it works for you?
> > > > > > > > > > 
> > > > > > > > > > Just get the latest Undertow, build the examples, then run:
> > > > > > > > > > 
> > > > > > > > > > mvn exec:exec
> > > > > > > > > > 
> > > > > > > > > > And select the file serving one, it should serve up you
> > > > > > > > > > home
> > > > > > > > > > directory.
> > > > > > > > > > 
> > > > > > > > > > Stuart
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Matthias Wessendorf" <matzew at redhat.com>
> > > > > > > > > > > To: undertow-dev at lists.jboss.org
> > > > > > > > > > > Sent: Sunday, 2 February, 2014 1:58:14 PM
> > > > > > > > > > > Subject: [undertow-dev] serving static files
> > > > > > > > > > > 
> > > > > > > > > > > Hello,
> > > > > > > > > > > 
> > > > > > > > > > > I might be just doing it wrong, but the following
> > > > > > > > > > > attempts
> > > > > > > > > > > are
> > > > > > > > > > > not
> > > > > > > > > > > successful
> > > > > > > > > > > for serving static files from a folder:
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > >         UndertowJaxrsServer ut = new
> > > > > > > > > > >         UndertowJaxrsServer();
> > > > > > > > > > >  
> > > > > > > > > > >         MyRestApplication app = new MyRestApplication();
> > > > > > > > > > >  
> > > > > > > > > > >         ut.deploy(app);
> > > > > > > > > > >  
> > > > > > > > > > >         ut.start(
> > > > > > > > > > >                 Undertow.builder()
> > > > > > > > > > >                         .addHttpListener(8080, "0.0.0.0")
> > > > > > > > > > > 
> > > > > > > > > > >  
> > > > > > > > > > >                 // first tried this:
> > > > > > > > > > >                         .setHandler(path()
> > > > > > > > > > >                                     .addPrefixPath("/",resource(new
> > > > > > > > > > >                                     FileResourceManager(new
> > > > > > > > > > >                                     File("/some/folder/containing/html/files"),
> > > > > > > > > > >                                     1024))))
> > > > > > > > > > >  
> > > > > > > > > > > 
> > > > > > > > > > >                 // afterwards also tried this:
> > > > > > > > > > >                         .setHandler(resource(new
> > > > > > > > > > >                         FileResourceManager(new
> > > > > > > > > > >                         File("/some/folder/containing/html/files"),
> > > > > > > > > > >                         1024)))
> > > > > > > > > > >         );
> > > > > > > > > > >  
> > > > > > > > > > >         try {
> > > > > > > > > > >             Thread.currentThread().join();
> > > > > > > > > > >         }
> > > > > > > > > > >         catch (InterruptedException e) {
> > > > > > > > > > >             logger.info("shutting down");
> > > > > > > > > > >             ut.stop();
> > > > > > > > > > >         }
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Not sure, but none of the above handlers seems to server
> > > > > > > > > > > files
> > > > > > > > > > > from
> > > > > > > > > > > a
> > > > > > > > > > > folder
> > > > > > > > > > > on my box
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Greetings,
> > > > > > > > > > > Matthias
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > --
> > > > > > > > > > > Matthias Wessendorf
> > > > > > > > > > > matzew at redhat.com
> > > > > > > > > > > 
> > > > > > > > > > > JBoss, by Red Hat
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > undertow-dev mailing list
> > > > > > > > > > > undertow-dev at lists.jboss.org
> > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > --
> > > > > > > > > Matthias Wessendorf
> > > > > > > > > matzew at redhat.com
> > > > > > > > > 
> > > > > > > > > JBoss, by Red Hat
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > > --
> > > > > > > Matthias Wessendorf
> > > > > > > matzew at redhat.com
> > > > > > > 
> > > > > > > JBoss, by Red Hat
> > > > > > > 
> > > > > > 
> > > > > 
> > > > > --
> > > > > Matthias Wessendorf
> > > > > matzew at redhat.com
> > > > > 
> > > > > JBoss, by Red Hat
> > > > > 
> > > > 
> > > 
> > > --
> > > Matthias Wessendorf
> > > matzew at redhat.com
> > > 
> > > JBoss, by Red Hat
> > > _______________________________________________
> > > undertow-dev mailing list
> > > undertow-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > > 
> > 
> > --
> > Matthias Wessendorf
> > matzew at redhat.com
> > 
> > JBoss, by Red Hat
> > 
> 

-- 
Matthias Wessendorf
matzew at redhat.com

JBoss, by Red Hat

From mondain at gmail.com  Thu Feb  6 02:36:34 2014
From: mondain at gmail.com (Mondain)
Date: Wed, 5 Feb 2014 23:36:34 -0800
Subject: [undertow-dev] Embedding undertow into Red5
Message-ID: <CAHQq8QKKccH-WOFW-WgRQyu2h=rkKBpWXTpXc3_ud_tAtFFdEw@mail.gmail.com>

I'm a core dev on the Red5 project and I would like to offer undertow as an
alternative to our current embedded tomcat server. I have read through the
examples, unit tests, and documentation regarding undertow. I have coded
and run my "plugin" implementation, but all I am getting are "Not Found"
responses in the browser. My suspicion is that the web.xml is not being
read in and / or parsed, but I'm not sure since I'm new with this code
base. Below you will see how I'm setting up and starting things; let me
know what I'm doing incorrectly.

//get a reference to the current threads classloader
final ClassLoader originalClassLoader =
Thread.currentThread().getContextClassLoader();
 // root location for servlet container
String serverRoot = System.getProperty("red5.root");
 String confRoot = System.getProperty("red5.config_root");
System.setProperty("UNDERTOW_HOME", serverRoot);
 if (webappFolder == null) {
// Use default webapps directory
webappFolder = FileUtil.formatPath(System.getProperty("red5.root"),
"/webapps");
 }
System.setProperty("red5.webapp.root", webappFolder);
// scan the sub directories to determine our context paths
 buildContextPathList(webappFolder);
try {
// create our servlet container
        container = ServletContainer.Factory.newInstance();
// create a root path handler
final PathHandler rootHandler = new PathHandler();
 // create one server and use it everywhere
Undertow.Builder builder = Undertow.builder();
// loop through connectors adding listeners to the builder
 for (UndertowConnector undertowConnector : connectors) {
InetSocketAddress addr = undertowConnector.getSocketAddress();
 builder.addListener(addr.getPort(), addr.getHostName(),
(undertowConnector.isSecure() ? ListenerType.HTTPS : ListenerType.HTTP));
}
 // loop the other contexts
for (String contextPath : contextPaths) {
// create a class loader for the context
 ClassLoader classLoader = buildWebClassLoader(originalClassLoader,
webappFolder, contextPath);
// create deployment info
 DeploymentInfo info = deployment()
                .setClassLoader(classLoader)
                .setContextPath(contextPath.equalsIgnoreCase("/ROOT") ? "/"
: contextPath)
                .setDefaultEncoding("UTF-8")
                .setDeploymentName(contextPath.substring(1) + ".war")
                .setUrlEncoding("UTF-8");
// add the new deployment to the servlet container
 DeploymentManager manager = container.addDeployment(info);
// deploy
manager.deploy();
 // add path
            rootHandler.addPrefixPath(info.getContextPath(),
manager.start());
// get deployment
 Deployment deployment = manager.getDeployment();
// get servlet context
final ServletContext servletContext = deployment.getServletContext();
 log.debug("Context initialized: {}", servletContext.getContextPath());
try {
log.debug("Context: {}", servletContext);
 final ClassLoader webClassLoader = info.getClassLoader();
log.debug("Webapp classloader: {}", webClassLoader);
 // get the (spring) config file path
final String contextConfigLocation =
servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONFIG_LOCATION_PARAM)
== null ? defaultSpringConfigLocation
 :
servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONFIG_LOCATION_PARAM);
log.debug("Spring context config location: {}", contextConfigLocation);
 // get the (spring) parent context key
final String parentContextKey =
servletContext.getInitParameter(org.springframework.web.context.ContextLoader.LOCATOR_FACTORY_KEY_PARAM)
== null ? defaultParentContextKey
 :
servletContext.getInitParameter(org.springframework.web.context.ContextLoader.LOCATOR_FACTORY_KEY_PARAM);
// set current threads classloader to the webapp classloader
 Thread.currentThread().setContextClassLoader(webClassLoader);
// create a thread to speed-up application loading
 Thread thread = new Thread("Launcher:" + servletContext.getContextPath()) {
public void run() {
 //set thread context classloader to web classloader
Thread.currentThread().setContextClassLoader(webClassLoader);
 //get the web app's parent context
ApplicationContext parentContext = null;
if (applicationContext.containsBean(parentContextKey)) {
 parentContext = (ApplicationContext)
applicationContext.getBean(parentContextKey);
} else {
 log.warn("Parent context was not found: {}", parentContextKey);
}
// create a spring web application context
 final String contextClass =
servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONTEXT_CLASS_PARAM)
== null ? XmlWebApplicationContext.class
 .getName() :
servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONTEXT_CLASS_PARAM);
// web app context (spring)
 ConfigurableWebApplicationContext appctx = null;
try {
Class<?> clazz = Class.forName(contextClass, true, webClassLoader);
 appctx = (ConfigurableWebApplicationContext) clazz.newInstance();
// set the root webapp ctx attr on the each servlet context so spring can
find it later
 servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE,
appctx);
appctx.setConfigLocations(new String[] { contextConfigLocation });
 appctx.setServletContext(servletContext);
// set parent context or use current app context
 if (parentContext != null) {
appctx.setParent(parentContext);
} else {
 appctx.setParent(applicationContext);
}
// refresh the factory
 appctx.refresh();
appctx.start();
} catch (Throwable e) {
 throw new RuntimeException("Failed to load webapplication context class",
e);
}
 }
};
thread.setDaemon(true);
thread.start();
 } catch (Throwable t) {
t.printStackTrace();
} finally {
 //reset the classloader
Thread.currentThread().setContextClassLoader(originalClassLoader);
}
 }
// Dump deployments list
if (log.isDebugEnabled()) {
 for (String deployment : container.listDeployments()) {
log.debug("Container deployment: {}", deployment);
 }
}
// add a root handler
builder.setHandler(rootHandler);
 // build the server instance
        server = builder.build();
log.info("Starting Undertow");
 server.start();
} catch (Exception e) {
if (e instanceof BindException || e.getMessage().indexOf("BindException")
!= -1) {
 log.error("Error loading undertow, unable to bind connector. You may not
have permission to use the selected port", e);
} else {
 log.error("Error loading undertow", e);
}
}



Regards,
Paul

-- 
http://gregoire.org/
http://code.google.com/p/red5/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140205/07ff415e/attachment.html 

From sdouglas at redhat.com  Thu Feb  6 03:33:06 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 6 Feb 2014 03:33:06 -0500 (EST)
Subject: [undertow-dev] Embedding undertow into Red5
In-Reply-To: <CAHQq8QKKccH-WOFW-WgRQyu2h=rkKBpWXTpXc3_ud_tAtFFdEw@mail.gmail.com>
References: <CAHQq8QKKccH-WOFW-WgRQyu2h=rkKBpWXTpXc3_ud_tAtFFdEw@mail.gmail.com>
Message-ID: <159930342.11840152.1391675586401.JavaMail.root@redhat.com>

----- Original Message -----

> From: "Mondain" <mondain at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Thursday, 6 February, 2014 9:36:34 AM
> Subject: [undertow-dev] Embedding undertow into Red5

> I'm a core dev on the Red5 project and I would like to offer undertow as an
> alternative to our current embedded tomcat server. I have read through the
> examples, unit tests, and documentation regarding undertow. I have coded and
> run my "plugin" implementation, but all I am getting are "Not Found"
> responses in the browser. My suspicion is that the web.xml is not being read
> in and / or parsed, but I'm not sure since I'm new with this code base.
> Below you will see how I'm setting up and starting things; let me know what
> I'm doing incorrectly.

Hi Mondain, 

You are correct in your suspicion that Undertow is not parsing the web.xml. Undertow provides an embedded Servlet implementation but it does not implement the discovery/parsing parts, as this is left up to the embedding application. 

Basically instead of using web.xml you need to add servlets, filters etc to the DeploymentInfo structure programatically. The main reason for this is basically because Undertow is designed to integrate well into other applications (especially Wildfly), and application servers generally provide their own implementation of parsers, annotation processors etc. 

With that said though at some point we will probably do a standalone parser/annotation processor to make this work out of the box (probably by just copying the relevant bits from wildfly and packaging them in their own jar). This is a fairly low priority item at the moment though. 

Stuart 

> //get a reference to the current threads classloader
> final ClassLoader originalClassLoader =
> Thread.currentThread().getContextClassLoader();
> // root location for servlet container
> String serverRoot = System.getProperty("red5.root");
> String confRoot = System.getProperty("red5.config_root");
> System.setProperty("UNDERTOW_HOME", serverRoot);
> if (webappFolder == null) {
> // Use default webapps directory
> webappFolder = FileUtil.formatPath(System.getProperty("red5.root"),
> "/webapps");
> }
> System.setProperty("red5.webapp.root", webappFolder);
> // scan the sub directories to determine our context paths
> buildContextPathList(webappFolder);
> try {
> // create our servlet container
> container = ServletContainer.Factory.newInstance();
> // create a root path handler
> final PathHandler rootHandler = new PathHandler();
> // create one server and use it everywhere
> Undertow.Builder builder = Undertow.builder();
> // loop through connectors adding listeners to the builder
> for (UndertowConnector undertowConnector : connectors) {
> InetSocketAddress addr = undertowConnector.getSocketAddress();
> builder.addListener(addr.getPort(), addr.getHostName(),
> (undertowConnector.isSecure() ? ListenerType.HTTPS : ListenerType.HTTP));
> }
> // loop the other contexts
> for (String contextPath : contextPaths) {
> // create a class loader for the context
> ClassLoader classLoader = buildWebClassLoader(originalClassLoader,
> webappFolder, contextPath);
> // create deployment info
> DeploymentInfo info = deployment()
> .setClassLoader(classLoader)
> .setContextPath(contextPath.equalsIgnoreCase("/ROOT") ? "/" : contextPath)
> .setDefaultEncoding("UTF-8")
> .setDeploymentName(contextPath.substring(1) + ".war")
> .setUrlEncoding("UTF-8");
> // add the new deployment to the servlet container
> DeploymentManager manager = container.addDeployment(info);
> // deploy
> manager.deploy();
> // add path
> rootHandler.addPrefixPath(info.getContextPath(), manager.start());
> // get deployment
> Deployment deployment = manager.getDeployment();
> // get servlet context
> final ServletContext servletContext = deployment.getServletContext();
> log.debug("Context initialized: {}", servletContext.getContextPath());
> try {
> log.debug("Context: {}", servletContext);
> final ClassLoader webClassLoader = info.getClassLoader();
> log.debug("Webapp classloader: {}", webClassLoader);
> // get the (spring) config file path
> final String contextConfigLocation =
> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONFIG_LOCATION_PARAM)
> == null ? defaultSpringConfigLocation
> :
> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONFIG_LOCATION_PARAM);
> log.debug("Spring context config location: {}", contextConfigLocation);
> // get the (spring) parent context key
> final String parentContextKey =
> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.LOCATOR_FACTORY_KEY_PARAM)
> == null ? defaultParentContextKey
> :
> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.LOCATOR_FACTORY_KEY_PARAM);
> // set current threads classloader to the webapp classloader
> Thread.currentThread().setContextClassLoader(webClassLoader);
> // create a thread to speed-up application loading
> Thread thread = new Thread("Launcher:" + servletContext.getContextPath()) {
> public void run() {
> //set thread context classloader to web classloader
> Thread.currentThread().setContextClassLoader(webClassLoader);
> //get the web app's parent context
> ApplicationContext parentContext = null;
> if (applicationContext.containsBean(parentContextKey)) {
> parentContext = (ApplicationContext)
> applicationContext.getBean(parentContextKey);
> } else {
> log.warn("Parent context was not found: {}", parentContextKey);
> }
> // create a spring web application context
> final String contextClass =
> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONTEXT_CLASS_PARAM)
> == null ? XmlWebApplicationContext.class
> .getName() :
> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONTEXT_CLASS_PARAM);
> // web app context (spring)
> ConfigurableWebApplicationContext appctx = null;
> try {
> Class<?> clazz = Class.forName(contextClass, true, webClassLoader);
> appctx = (ConfigurableWebApplicationContext) clazz.newInstance();
> // set the root webapp ctx attr on the each servlet context so spring can
> find it later
> servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE,
> appctx);
> appctx.setConfigLocations(new String[] { contextConfigLocation });
> appctx.setServletContext(servletContext);
> // set parent context or use current app context
> if (parentContext != null) {
> appctx.setParent(parentContext);
> } else {
> appctx.setParent(applicationContext);
> }
> // refresh the factory
> appctx.refresh();
> appctx.start();
> } catch (Throwable e) {
> throw new RuntimeException("Failed to load webapplication context class", e);
> }
> }
> };
> thread.setDaemon(true);
> thread.start();
> } catch (Throwable t) {
> t.printStackTrace();
> } finally {
> //reset the classloader
> Thread.currentThread().setContextClassLoader(originalClassLoader);
> }
> }
> // Dump deployments list
> if (log.isDebugEnabled()) {
> for (String deployment : container.listDeployments()) {
> log.debug("Container deployment: {}", deployment);
> }
> }
> // add a root handler
> builder.setHandler(rootHandler);
> // build the server instance
> server = builder.build();
> log.info ("Starting Undertow");
> server.start();
> } catch (Exception e) {
> if (e instanceof BindException || e.getMessage().indexOf("BindException") !=
> -1) {
> log.error("Error loading undertow, unable to bind connector. You may not have
> permission to use the selected port", e);
> } else {
> log.error("Error loading undertow", e);
> }
> }

> Regards,
> Paul

> --
> http://gregoire.org/
> http://code.google.com/p/red5/

> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140206/9f240bcc/attachment-0001.html 

From mondain at gmail.com  Thu Feb  6 10:35:12 2014
From: mondain at gmail.com (Mondain)
Date: Thu, 6 Feb 2014 07:35:12 -0800
Subject: [undertow-dev] Embedding undertow into Red5
In-Reply-To: <159930342.11840152.1391675586401.JavaMail.root@redhat.com>
References: <CAHQq8QKKccH-WOFW-WgRQyu2h=rkKBpWXTpXc3_ud_tAtFFdEw@mail.gmail.com>
	<159930342.11840152.1391675586401.JavaMail.root@redhat.com>
Message-ID: <CAHQq8QJ3vny5YCzwarBJABQHshBt2vcVDcn6mPwVbY_E2DG8JA@mail.gmail.com>

Thanks for the reply, now I know I have more work to do.


On Thu, Feb 6, 2014 at 12:33 AM, Stuart Douglas <sdouglas at redhat.com> wrote:

>
>
> ------------------------------
>
> *From: *"Mondain" <mondain at gmail.com>
> *To: *undertow-dev at lists.jboss.org
> *Sent: *Thursday, 6 February, 2014 9:36:34 AM
> *Subject: *[undertow-dev] Embedding undertow into Red5
>
>
> I'm a core dev on the Red5 project and I would like to offer undertow as
> an alternative to our current embedded tomcat server. I have read through
> the examples, unit tests, and documentation regarding undertow. I have
> coded and run my "plugin" implementation, but all I am getting are "Not
> Found" responses in the browser. My suspicion is that the web.xml is not
> being read in and / or parsed, but I'm not sure since I'm new with this
> code base. Below you will see how I'm setting up and starting things; let
> me know what I'm doing incorrectly.
>
> Hi Mondain,
>
> You are correct in your suspicion that Undertow is not parsing the
> web.xml. Undertow provides an embedded Servlet implementation but it does
> not implement the discovery/parsing parts, as this is left up to the
> embedding application.
>
> Basically instead of using web.xml you need to add servlets, filters etc
> to the DeploymentInfo structure programatically. The main reason for this
> is basically because Undertow is designed to integrate well into other
> applications (especially Wildfly), and application servers generally
> provide their own implementation of parsers, annotation processors etc.
>
> With that said though at some point we will probably do a standalone
> parser/annotation processor to make this work out of the box (probably by
> just copying the relevant bits from wildfly and packaging them in their own
> jar). This is a fairly low priority item at the moment though.
>
> Stuart
>
>
>
>
>
> //get a reference to the current threads classloader
> final ClassLoader originalClassLoader =
> Thread.currentThread().getContextClassLoader();
>  // root location for servlet container
> String serverRoot = System.getProperty("red5.root");
> String confRoot = System.getProperty("red5.config_root");
>  System.setProperty("UNDERTOW_HOME", serverRoot);
> if (webappFolder == null) {
> // Use default webapps directory
>  webappFolder = FileUtil.formatPath(System.getProperty("red5.root"),
> "/webapps");
> }
> System.setProperty("red5.webapp.root", webappFolder);
>  // scan the sub directories to determine our context paths
> buildContextPathList(webappFolder);
> try {
>  // create our servlet container
>         container = ServletContainer.Factory.newInstance();
> // create a root path handler
>  final PathHandler rootHandler = new PathHandler();
> // create one server and use it everywhere
> Undertow.Builder builder = Undertow.builder();
>  // loop through connectors adding listeners to the builder
> for (UndertowConnector undertowConnector : connectors) {
>  InetSocketAddress addr = undertowConnector.getSocketAddress();
> builder.addListener(addr.getPort(), addr.getHostName(),
> (undertowConnector.isSecure() ? ListenerType.HTTPS : ListenerType.HTTP));
>  }
> // loop the other contexts
> for (String contextPath : contextPaths) {
>  // create a class loader for the context
> ClassLoader classLoader = buildWebClassLoader(originalClassLoader,
> webappFolder, contextPath);
>  // create deployment info
> DeploymentInfo info = deployment()
>                 .setClassLoader(classLoader)
>                 .setContextPath(contextPath.equalsIgnoreCase("/ROOT") ?
> "/" : contextPath)
>                 .setDefaultEncoding("UTF-8")
>                 .setDeploymentName(contextPath.substring(1) + ".war")
>                 .setUrlEncoding("UTF-8");
>  // add the new deployment to the servlet container
> DeploymentManager manager = container.addDeployment(info);
>  // deploy
> manager.deploy();
> // add path
>             rootHandler.addPrefixPath(info.getContextPath(),
> manager.start());
>  // get deployment
> Deployment deployment = manager.getDeployment();
> // get servlet context
>  final ServletContext servletContext = deployment.getServletContext();
> log.debug("Context initialized: {}", servletContext.getContextPath());
>  try {
> log.debug("Context: {}", servletContext);
> final ClassLoader webClassLoader = info.getClassLoader();
>  log.debug("Webapp classloader: {}", webClassLoader);
> // get the (spring) config file path
> final String contextConfigLocation =
> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONFIG_LOCATION_PARAM)
> == null ? defaultSpringConfigLocation
>  :
> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONFIG_LOCATION_PARAM);
> log.debug("Spring context config location: {}", contextConfigLocation);
>  // get the (spring) parent context key
> final String parentContextKey =
> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.LOCATOR_FACTORY_KEY_PARAM)
> == null ? defaultParentContextKey
>  :
> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.LOCATOR_FACTORY_KEY_PARAM);
> // set current threads classloader to the webapp classloader
>  Thread.currentThread().setContextClassLoader(webClassLoader);
> // create a thread to speed-up application loading
>  Thread thread = new Thread("Launcher:" +
> servletContext.getContextPath()) {
> public void run() {
>  //set thread context classloader to web classloader
> Thread.currentThread().setContextClassLoader(webClassLoader);
>  //get the web app's parent context
> ApplicationContext parentContext = null;
> if (applicationContext.containsBean(parentContextKey)) {
>  parentContext = (ApplicationContext)
> applicationContext.getBean(parentContextKey);
> } else {
> log.warn("Parent context was not found: {}", parentContextKey);
>  }
> // create a spring web application context
> final String contextClass =
> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONTEXT_CLASS_PARAM)
> == null ? XmlWebApplicationContext.class
>  .getName() :
> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONTEXT_CLASS_PARAM);
> // web app context (spring)
>  ConfigurableWebApplicationContext appctx = null;
> try {
> Class<?> clazz = Class.forName(contextClass, true, webClassLoader);
>  appctx = (ConfigurableWebApplicationContext) clazz.newInstance();
> // set the root webapp ctx attr on the each servlet context so spring can
> find it later
>  servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE,
> appctx);
> appctx.setConfigLocations(new String[] { contextConfigLocation });
>  appctx.setServletContext(servletContext);
> // set parent context or use current app context
> if (parentContext != null) {
>  appctx.setParent(parentContext);
> } else {
> appctx.setParent(applicationContext);
>  }
> // refresh the factory
> appctx.refresh();
>  appctx.start();
> } catch (Throwable e) {
> throw new RuntimeException("Failed to load webapplication context class",
> e);
>  }
> }
> };
> thread.setDaemon(true);
>  thread.start();
> } catch (Throwable t) {
> t.printStackTrace();
>  } finally {
> //reset the classloader
> Thread.currentThread().setContextClassLoader(originalClassLoader);
>  }
> }
> // Dump deployments list
> if (log.isDebugEnabled()) {
>  for (String deployment : container.listDeployments()) {
> log.debug("Container deployment: {}", deployment);
>  }
> }
> // add a root handler
> builder.setHandler(rootHandler);
>  // build the server instance
>         server = builder.build();
> log.info("Starting Undertow");
>  server.start();
> } catch (Exception e) {
> if (e instanceof BindException || e.getMessage().indexOf("BindException")
> != -1) {
>  log.error("Error loading undertow, unable to bind connector. You may not
> have permission to use the selected port", e);
> } else {
>  log.error("Error loading undertow", e);
> }
> }
>
>
>
> Regards,
> Paul
>
> --
> http://gregoire.org/
> http://code.google.com/p/red5/
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
>


-- 
http://gregoire.org/
http://code.google.com/p/red5/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140206/ebae24ef/attachment.html 

From mondain at gmail.com  Thu Feb  6 12:45:51 2014
From: mondain at gmail.com (Mondain)
Date: Thu, 6 Feb 2014 09:45:51 -0800
Subject: [undertow-dev] Embedding undertow into Red5
In-Reply-To: <CAHQq8QJ3vny5YCzwarBJABQHshBt2vcVDcn6mPwVbY_E2DG8JA@mail.gmail.com>
References: <CAHQq8QKKccH-WOFW-WgRQyu2h=rkKBpWXTpXc3_ud_tAtFFdEw@mail.gmail.com>
	<159930342.11840152.1391675586401.JavaMail.root@redhat.com>
	<CAHQq8QJ3vny5YCzwarBJABQHshBt2vcVDcn6mPwVbY_E2DG8JA@mail.gmail.com>
Message-ID: <CAHQq8QKy+G-GOMKTRfDV9bdGz_rNkWzghj3HqT4X_K6Xi3Bhdg@mail.gmail.com>

I've got a first rev of my web.xml parser now and I've run into a curious
thing regarding filters. How do I add the url-pattern to a FilterInfo
mapping as I do with a ServletInfo mapping?





On Thu, Feb 6, 2014 at 7:35 AM, Mondain <mondain at gmail.com> wrote:

> Thanks for the reply, now I know I have more work to do.
>
>
> On Thu, Feb 6, 2014 at 12:33 AM, Stuart Douglas <sdouglas at redhat.com>wrote:
>
>>
>>
>> ------------------------------
>>
>> *From: *"Mondain" <mondain at gmail.com>
>> *To: *undertow-dev at lists.jboss.org
>> *Sent: *Thursday, 6 February, 2014 9:36:34 AM
>> *Subject: *[undertow-dev] Embedding undertow into Red5
>>
>>
>> I'm a core dev on the Red5 project and I would like to offer undertow as
>> an alternative to our current embedded tomcat server. I have read through
>> the examples, unit tests, and documentation regarding undertow. I have
>> coded and run my "plugin" implementation, but all I am getting are "Not
>> Found" responses in the browser. My suspicion is that the web.xml is not
>> being read in and / or parsed, but I'm not sure since I'm new with this
>> code base. Below you will see how I'm setting up and starting things; let
>> me know what I'm doing incorrectly.
>>
>> Hi Mondain,
>>
>> You are correct in your suspicion that Undertow is not parsing the
>> web.xml. Undertow provides an embedded Servlet implementation but it does
>> not implement the discovery/parsing parts, as this is left up to the
>> embedding application.
>>
>> Basically instead of using web.xml you need to add servlets, filters etc
>> to the DeploymentInfo structure programatically. The main reason for this
>> is basically because Undertow is designed to integrate well into other
>> applications (especially Wildfly), and application servers generally
>> provide their own implementation of parsers, annotation processors etc.
>>
>> With that said though at some point we will probably do a standalone
>> parser/annotation processor to make this work out of the box (probably by
>> just copying the relevant bits from wildfly and packaging them in their own
>> jar). This is a fairly low priority item at the moment though.
>>
>> Stuart
>>
>>
>>
>>
>>
>> //get a reference to the current threads classloader
>> final ClassLoader originalClassLoader =
>> Thread.currentThread().getContextClassLoader();
>>  // root location for servlet container
>> String serverRoot = System.getProperty("red5.root");
>> String confRoot = System.getProperty("red5.config_root");
>>  System.setProperty("UNDERTOW_HOME", serverRoot);
>> if (webappFolder == null) {
>> // Use default webapps directory
>>  webappFolder = FileUtil.formatPath(System.getProperty("red5.root"),
>> "/webapps");
>> }
>> System.setProperty("red5.webapp.root", webappFolder);
>>  // scan the sub directories to determine our context paths
>> buildContextPathList(webappFolder);
>> try {
>>  // create our servlet container
>>         container = ServletContainer.Factory.newInstance();
>> // create a root path handler
>>  final PathHandler rootHandler = new PathHandler();
>> // create one server and use it everywhere
>> Undertow.Builder builder = Undertow.builder();
>>  // loop through connectors adding listeners to the builder
>> for (UndertowConnector undertowConnector : connectors) {
>>  InetSocketAddress addr = undertowConnector.getSocketAddress();
>> builder.addListener(addr.getPort(), addr.getHostName(),
>> (undertowConnector.isSecure() ? ListenerType.HTTPS : ListenerType.HTTP));
>>  }
>> // loop the other contexts
>> for (String contextPath : contextPaths) {
>>  // create a class loader for the context
>> ClassLoader classLoader = buildWebClassLoader(originalClassLoader,
>> webappFolder, contextPath);
>>  // create deployment info
>> DeploymentInfo info = deployment()
>>                 .setClassLoader(classLoader)
>>                 .setContextPath(contextPath.equalsIgnoreCase("/ROOT") ?
>> "/" : contextPath)
>>                 .setDefaultEncoding("UTF-8")
>>                 .setDeploymentName(contextPath.substring(1) + ".war")
>>                 .setUrlEncoding("UTF-8");
>>  // add the new deployment to the servlet container
>> DeploymentManager manager = container.addDeployment(info);
>>  // deploy
>> manager.deploy();
>> // add path
>>             rootHandler.addPrefixPath(info.getContextPath(),
>> manager.start());
>>  // get deployment
>> Deployment deployment = manager.getDeployment();
>> // get servlet context
>>  final ServletContext servletContext = deployment.getServletContext();
>> log.debug("Context initialized: {}", servletContext.getContextPath());
>>  try {
>> log.debug("Context: {}", servletContext);
>> final ClassLoader webClassLoader = info.getClassLoader();
>>  log.debug("Webapp classloader: {}", webClassLoader);
>> // get the (spring) config file path
>> final String contextConfigLocation =
>> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONFIG_LOCATION_PARAM)
>> == null ? defaultSpringConfigLocation
>>  :
>> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONFIG_LOCATION_PARAM);
>> log.debug("Spring context config location: {}", contextConfigLocation);
>>  // get the (spring) parent context key
>> final String parentContextKey =
>> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.LOCATOR_FACTORY_KEY_PARAM)
>> == null ? defaultParentContextKey
>>  :
>> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.LOCATOR_FACTORY_KEY_PARAM);
>> // set current threads classloader to the webapp classloader
>>  Thread.currentThread().setContextClassLoader(webClassLoader);
>> // create a thread to speed-up application loading
>>  Thread thread = new Thread("Launcher:" +
>> servletContext.getContextPath()) {
>> public void run() {
>>  //set thread context classloader to web classloader
>> Thread.currentThread().setContextClassLoader(webClassLoader);
>>  //get the web app's parent context
>> ApplicationContext parentContext = null;
>> if (applicationContext.containsBean(parentContextKey)) {
>>  parentContext = (ApplicationContext)
>> applicationContext.getBean(parentContextKey);
>> } else {
>> log.warn("Parent context was not found: {}", parentContextKey);
>>  }
>> // create a spring web application context
>> final String contextClass =
>> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONTEXT_CLASS_PARAM)
>> == null ? XmlWebApplicationContext.class
>>  .getName() :
>> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONTEXT_CLASS_PARAM);
>> // web app context (spring)
>>  ConfigurableWebApplicationContext appctx = null;
>> try {
>> Class<?> clazz = Class.forName(contextClass, true, webClassLoader);
>>  appctx = (ConfigurableWebApplicationContext) clazz.newInstance();
>> // set the root webapp ctx attr on the each servlet context so spring can
>> find it later
>>  servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE,
>> appctx);
>> appctx.setConfigLocations(new String[] { contextConfigLocation });
>>  appctx.setServletContext(servletContext);
>> // set parent context or use current app context
>> if (parentContext != null) {
>>  appctx.setParent(parentContext);
>> } else {
>> appctx.setParent(applicationContext);
>>  }
>> // refresh the factory
>> appctx.refresh();
>>  appctx.start();
>> } catch (Throwable e) {
>> throw new RuntimeException("Failed to load webapplication context class",
>> e);
>>  }
>> }
>> };
>> thread.setDaemon(true);
>>  thread.start();
>> } catch (Throwable t) {
>> t.printStackTrace();
>>  } finally {
>> //reset the classloader
>> Thread.currentThread().setContextClassLoader(originalClassLoader);
>>  }
>> }
>> // Dump deployments list
>> if (log.isDebugEnabled()) {
>>  for (String deployment : container.listDeployments()) {
>> log.debug("Container deployment: {}", deployment);
>>  }
>> }
>> // add a root handler
>> builder.setHandler(rootHandler);
>>  // build the server instance
>>         server = builder.build();
>> log.info("Starting Undertow");
>>  server.start();
>> } catch (Exception e) {
>> if (e instanceof BindException || e.getMessage().indexOf("BindException")
>> != -1) {
>>  log.error("Error loading undertow, unable to bind connector. You may
>> not have permission to use the selected port", e);
>> } else {
>>  log.error("Error loading undertow", e);
>> }
>> }
>>
>>
>>
>> Regards,
>> Paul
>>
>> --
>> http://gregoire.org/
>> http://code.google.com/p/red5/
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>>
>>
>
>
> --
> http://gregoire.org/
> http://code.google.com/p/red5/
>



-- 
http://gregoire.org/
http://code.google.com/p/red5/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140206/3e2c5e1d/attachment-0001.html 

From sdouglas at redhat.com  Fri Feb  7 06:42:10 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 7 Feb 2014 06:42:10 -0500 (EST)
Subject: [undertow-dev] Embedding undertow into Red5
In-Reply-To: <CAHQq8QKy+G-GOMKTRfDV9bdGz_rNkWzghj3HqT4X_K6Xi3Bhdg@mail.gmail.com>
References: <CAHQq8QKKccH-WOFW-WgRQyu2h=rkKBpWXTpXc3_ud_tAtFFdEw@mail.gmail.com>
	<159930342.11840152.1391675586401.JavaMail.root@redhat.com>
	<CAHQq8QJ3vny5YCzwarBJABQHshBt2vcVDcn6mPwVbY_E2DG8JA@mail.gmail.com>
	<CAHQq8QKy+G-GOMKTRfDV9bdGz_rNkWzghj3HqT4X_K6Xi3Bhdg@mail.gmail.com>
Message-ID: <1484027787.12482819.1391773330330.JavaMail.root@redhat.com>

You need to add the filter mapping directly to the DeploymentInfo structure using addFilterUrlMapping or addFilterServletNameMapping.

This is because there is a global ordering of filter mappings that determines the order filters get invoked in, while there is no such concept for Servlets.

Stuart

----- Original Message -----
> From: "Mondain" <mondain at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Thursday, 6 February, 2014 7:45:51 PM
> Subject: Re: [undertow-dev] Embedding undertow into Red5
> 
> I've got a first rev of my web.xml parser now and I've run into a curious
> thing regarding filters. How do I add the url-pattern to a FilterInfo
> mapping as I do with a ServletInfo mapping?
> 
> 
> 
> 
> 
> On Thu, Feb 6, 2014 at 7:35 AM, Mondain < mondain at gmail.com > wrote:
> 
> 
> 
> Thanks for the reply, now I know I have more work to do.
> 
> 
> On Thu, Feb 6, 2014 at 12:33 AM, Stuart Douglas < sdouglas at redhat.com >
> wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> From: "Mondain" < mondain at gmail.com >
> To: undertow-dev at lists.jboss.org
> Sent: Thursday, 6 February, 2014 9:36:34 AM
> Subject: [undertow-dev] Embedding undertow into Red5
> 
> 
> I'm a core dev on the Red5 project and I would like to offer undertow as an
> alternative to our current embedded tomcat server. I have read through the
> examples, unit tests, and documentation regarding undertow. I have coded and
> run my "plugin" implementation, but all I am getting are "Not Found"
> responses in the browser. My suspicion is that the web.xml is not being read
> in and / or parsed, but I'm not sure since I'm new with this code base.
> Below you will see how I'm setting up and starting things; let me know what
> I'm doing incorrectly.
> Hi Mondain,
> 
> You are correct in your suspicion that Undertow is not parsing the web.xml.
> Undertow provides an embedded Servlet implementation but it does not
> implement the discovery/parsing parts, as this is left up to the embedding
> application.
> 
> Basically instead of using web.xml you need to add servlets, filters etc to
> the DeploymentInfo structure programatically. The main reason for this is
> basically because Undertow is designed to integrate well into other
> applications (especially Wildfly), and application servers generally provide
> their own implementation of parsers, annotation processors etc.
> 
> With that said though at some point we will probably do a standalone
> parser/annotation processor to make this work out of the box (probably by
> just copying the relevant bits from wildfly and packaging them in their own
> jar). This is a fairly low priority item at the moment though.
> 
> Stuart
> 
> 
> 
> 
> 
> 
> 
> 
> //get a reference to the current threads classloader
> final ClassLoader originalClassLoader =
> Thread.currentThread().getContextClassLoader();
> // root location for servlet container
> String serverRoot = System.getProperty("red5.root");
> String confRoot = System.getProperty("red5.config_root");
> System.setProperty("UNDERTOW_HOME", serverRoot);
> if (webappFolder == null) {
> // Use default webapps directory
> webappFolder = FileUtil.formatPath(System.getProperty("red5.root"),
> "/webapps");
> }
> System.setProperty("red5.webapp.root", webappFolder);
> // scan the sub directories to determine our context paths
> buildContextPathList(webappFolder);
> try {
> // create our servlet container
> container = ServletContainer.Factory.newInstance();
> // create a root path handler
> final PathHandler rootHandler = new PathHandler();
> // create one server and use it everywhere
> Undertow.Builder builder = Undertow.builder();
> // loop through connectors adding listeners to the builder
> for (UndertowConnector undertowConnector : connectors) {
> InetSocketAddress addr = undertowConnector.getSocketAddress();
> builder.addListener(addr.getPort(), addr.getHostName(),
> (undertowConnector.isSecure() ? ListenerType.HTTPS : ListenerType.HTTP));
> }
> // loop the other contexts
> for (String contextPath : contextPaths) {
> // create a class loader for the context
> ClassLoader classLoader = buildWebClassLoader(originalClassLoader,
> webappFolder, contextPath);
> // create deployment info
> DeploymentInfo info = deployment()
> .setClassLoader(classLoader)
> .setContextPath(contextPath.equalsIgnoreCase("/ROOT") ? "/" : contextPath)
> .setDefaultEncoding("UTF-8")
> .setDeploymentName(contextPath.substring(1) + ".war")
> .setUrlEncoding("UTF-8");
> // add the new deployment to the servlet container
> DeploymentManager manager = container.addDeployment(info);
> // deploy
> manager.deploy();
> // add path
> rootHandler.addPrefixPath(info.getContextPath(), manager.start());
> // get deployment
> Deployment deployment = manager.getDeployment();
> // get servlet context
> final ServletContext servletContext = deployment.getServletContext();
> log.debug("Context initialized: {}", servletContext.getContextPath());
> try {
> log.debug("Context: {}", servletContext);
> final ClassLoader webClassLoader = info.getClassLoader();
> log.debug("Webapp classloader: {}", webClassLoader);
> // get the (spring) config file path
> final String contextConfigLocation =
> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONFIG_LOCATION_PARAM)
> == null ? defaultSpringConfigLocation
> :
> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONFIG_LOCATION_PARAM);
> log.debug("Spring context config location: {}", contextConfigLocation);
> // get the (spring) parent context key
> final String parentContextKey =
> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.LOCATOR_FACTORY_KEY_PARAM)
> == null ? defaultParentContextKey
> :
> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.LOCATOR_FACTORY_KEY_PARAM);
> // set current threads classloader to the webapp classloader
> Thread.currentThread().setContextClassLoader(webClassLoader);
> // create a thread to speed-up application loading
> Thread thread = new Thread("Launcher:" + servletContext.getContextPath()) {
> public void run() {
> //set thread context classloader to web classloader
> Thread.currentThread().setContextClassLoader(webClassLoader);
> //get the web app's parent context
> ApplicationContext parentContext = null;
> if (applicationContext.containsBean(parentContextKey)) {
> parentContext = (ApplicationContext)
> applicationContext.getBean(parentContextKey);
> } else {
> log.warn("Parent context was not found: {}", parentContextKey);
> }
> // create a spring web application context
> final String contextClass =
> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONTEXT_CLASS_PARAM)
> == null ? XmlWebApplicationContext.class
> .getName() :
> servletContext.getInitParameter(org.springframework.web.context.ContextLoader.CONTEXT_CLASS_PARAM);
> // web app context (spring)
> ConfigurableWebApplicationContext appctx = null;
> try {
> Class<?> clazz = Class.forName(contextClass, true, webClassLoader);
> appctx = (ConfigurableWebApplicationContext) clazz.newInstance();
> // set the root webapp ctx attr on the each servlet context so spring can
> find it later
> servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE,
> appctx);
> appctx.setConfigLocations(new String[] { contextConfigLocation });
> appctx.setServletContext(servletContext);
> // set parent context or use current app context
> if (parentContext != null) {
> appctx.setParent(parentContext);
> } else {
> appctx.setParent(applicationContext);
> }
> // refresh the factory
> appctx.refresh();
> appctx.start();
> } catch (Throwable e) {
> throw new RuntimeException("Failed to load webapplication context class", e);
> }
> }
> };
> thread.setDaemon(true);
> thread.start();
> } catch (Throwable t) {
> t.printStackTrace();
> } finally {
> //reset the classloader
> Thread.currentThread().setContextClassLoader(originalClassLoader);
> }
> }
> // Dump deployments list
> if (log.isDebugEnabled()) {
> for (String deployment : container.listDeployments()) {
> log.debug("Container deployment: {}", deployment);
> }
> }
> // add a root handler
> builder.setHandler(rootHandler);
> // build the server instance
> server = builder.build();
> log.info ("Starting Undertow");
> server.start();
> } catch (Exception e) {
> if (e instanceof BindException || e.getMessage().indexOf("BindException") !=
> -1) {
> log.error("Error loading undertow, unable to bind connector. You may not have
> permission to use the selected port", e);
> } else {
> log.error("Error loading undertow", e);
> }
> }
> 
> 
> 
> Regards,
> Paul
> 
> --
> http://gregoire.org/
> http://code.google.com/p/red5/
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 
> 
> 
> --
> http://gregoire.org/
> http://code.google.com/p/red5/
> 
> 
> 
> --
> http://gregoire.org/
> http://code.google.com/p/red5/
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From bburke at redhat.com  Fri Feb  7 13:15:00 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 07 Feb 2014 13:15:00 -0500
Subject: [undertow-dev] accessing msc services
Message-ID: <52F522A4.7020201@redhat.com>

Is there any way to get an msc service from the WIldfly subsystem layer 
from inside an Undertow handler?
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From tomaz.cerar at gmail.com  Fri Feb  7 13:21:27 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Fri, 7 Feb 2014 19:21:27 +0100
Subject: [undertow-dev] accessing msc services
In-Reply-To: <52F522A4.7020201@redhat.com>
References: <52F522A4.7020201@redhat.com>
Message-ID: <CAMquZP6T5QT6ArHoMQ0bT5=May28A=amv2_1x3GhnNoEjZaTMg@mail.gmail.com>

Only way that comes to my mind would be an ugly one.

that is accessing static ServiceRegistry and looking up service there.

we could how ever add some extra handler to handler chain that would add
some msc related APIs as an attachment.

What exactly is your use case?

Maybe it could be done another way around, for example when creating /
registering your handler which should be done deployment time instead of
runtime.
it would also be faster.

--
tomaz


On Fri, Feb 7, 2014 at 7:15 PM, Bill Burke <bburke at redhat.com> wrote:

> Is there any way to get an msc service from the WIldfly subsystem layer
> from inside an Undertow handler?
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140207/72222ebb/attachment.html 

From bburke at redhat.com  Fri Feb  7 15:51:07 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 07 Feb 2014 15:51:07 -0500
Subject: [undertow-dev] accessing msc services
In-Reply-To: <CAMquZP6T5QT6ArHoMQ0bT5=May28A=amv2_1x3GhnNoEjZaTMg@mail.gmail.com>
References: <52F522A4.7020201@redhat.com>
	<CAMquZP6T5QT6ArHoMQ0bT5=May28A=amv2_1x3GhnNoEjZaTMg@mail.gmail.com>
Message-ID: <52F5473B.2060609@redhat.com>

I just need a reference to this service as it contains config 
information that is stored in the subsystem (standalone.xml, sorry if 
I'm confusing the terminology).  Don't care where or when the Undertow 
Handler gets this referenc(deploy time or runtime).

Is it possible to create HttpHandler instances in a deployment processor 
and attach them to the WAR deployment?  What about AuthMechanisms?  I 
guess I should dive into the undertow subsystem a bit more.

On 2/7/2014 1:21 PM, Toma? Cerar wrote:
> Only way that comes to my mind would be an ugly one.
>
> that is accessing static ServiceRegistry and looking up service there.
>
> we could how ever add some extra handler to handler chain that would add
> some msc related APIs as an attachment.
>
> What exactly is your use case?
>
> Maybe it could be done another way around, for example when creating /
> registering your handler which should be done deployment time instead of
> runtime.
> it would also be faster.
>
> --
> tomaz
>
>
> On Fri, Feb 7, 2014 at 7:15 PM, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>     Is there any way to get an msc service from the WIldfly subsystem layer
>     from inside an Undertow handler?
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>     _______________________________________________
>     undertow-dev mailing list
>     undertow-dev at lists.jboss.org <mailto:undertow-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From tomaz.cerar at gmail.com  Fri Feb  7 15:53:01 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Fri, 7 Feb 2014 21:53:01 +0100
Subject: [undertow-dev] accessing msc services
In-Reply-To: <52F5473B.2060609@redhat.com>
References: <52F522A4.7020201@redhat.com>
	<CAMquZP6T5QT6ArHoMQ0bT5=May28A=amv2_1x3GhnNoEjZaTMg@mail.gmail.com>
	<52F5473B.2060609@redhat.com>
Message-ID: <CAMquZP5mfytZ1=q6aR9yO-Wmr2H_FgSeyjYDDxWrU9DtZ1VOTQ@mail.gmail.com>

On Fri, Feb 7, 2014 at 9:51 PM, Bill Burke <bburke at redhat.com> wrote:

> I just need a reference to this service as it contains config information
> that is stored in the subsystem (standalone.xml, sorry if I'm confusing the
> terminology).  Don't care where or when the Undertow Handler gets this
> referenc(deploy time or runtime).
>
> Is it possible to create HttpHandler instances in a deployment processor
> and attach them to the WAR deployment?  What about AuthMechanisms?  I guess
> I should dive into the undertow subsystem a bit more.
>


Yeah it is possible create & attach http handlers to the chain inside your
deployment processor, same for auth mechanisms.
There are many subsystems that already do exactly this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140207/3949272a/attachment.html 

From bburke at redhat.com  Fri Feb  7 16:10:26 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 07 Feb 2014 16:10:26 -0500
Subject: [undertow-dev] accessing msc services
In-Reply-To: <CAMquZP5mfytZ1=q6aR9yO-Wmr2H_FgSeyjYDDxWrU9DtZ1VOTQ@mail.gmail.com>
References: <52F522A4.7020201@redhat.com>	<CAMquZP6T5QT6ArHoMQ0bT5=May28A=amv2_1x3GhnNoEjZaTMg@mail.gmail.com>	<52F5473B.2060609@redhat.com>
	<CAMquZP5mfytZ1=q6aR9yO-Wmr2H_FgSeyjYDDxWrU9DtZ1VOTQ@mail.gmail.com>
Message-ID: <52F54BC2.2090901@redhat.com>



On 2/7/2014 3:53 PM, Toma? Cerar wrote:
>
> On Fri, Feb 7, 2014 at 9:51 PM, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>     I just need a reference to this service as it contains config
>     information that is stored in the subsystem (standalone.xml, sorry
>     if I'm confusing the terminology).  Don't care where or when the
>     Undertow Handler gets this referenc(deploy time or runtime).
>
>     Is it possible to create HttpHandler instances in a deployment
>     processor and attach them to the WAR deployment?  What about
>     AuthMechanisms?  I guess I should dive into the undertow subsystem a
>     bit more.
>
>
>
> Yeah it is possible create & attach http handlers to the chain inside
> your deployment processor, same for auth mechanisms.
> There are many subsystems that already do exactly this.

Awesome. Ok, that's all I needed.  I'll search the codebase.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From sdouglas at redhat.com  Fri Feb  7 22:21:39 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 7 Feb 2014 22:21:39 -0500 (EST)
Subject: [undertow-dev] accessing msc services
In-Reply-To: <52F54BC2.2090901@redhat.com>
References: <52F522A4.7020201@redhat.com>
	<CAMquZP6T5QT6ArHoMQ0bT5=May28A=amv2_1x3GhnNoEjZaTMg@mail.gmail.com>
	<52F5473B.2060609@redhat.com>
	<CAMquZP5mfytZ1=q6aR9yO-Wmr2H_FgSeyjYDDxWrU9DtZ1VOTQ@mail.gmail.com>
	<52F54BC2.2090901@redhat.com>
Message-ID: <818173510.2984.1391829699000.JavaMail.zimbra@redhat.com>

To save you looking the relevant class is org.wildfly.extension.undertow.deployment.UndertowAttachments.

Stuart

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Toma? Cerar" <tomaz.cerar at gmail.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Friday, 7 February, 2014 11:10:26 PM
> Subject: Re: [undertow-dev] accessing msc services
> 
> 
> 
> On 2/7/2014 3:53 PM, Toma? Cerar wrote:
> >
> > On Fri, Feb 7, 2014 at 9:51 PM, Bill Burke <bburke at redhat.com
> > <mailto:bburke at redhat.com>> wrote:
> >
> >     I just need a reference to this service as it contains config
> >     information that is stored in the subsystem (standalone.xml, sorry
> >     if I'm confusing the terminology).  Don't care where or when the
> >     Undertow Handler gets this referenc(deploy time or runtime).
> >
> >     Is it possible to create HttpHandler instances in a deployment
> >     processor and attach them to the WAR deployment?  What about
> >     AuthMechanisms?  I guess I should dive into the undertow subsystem a
> >     bit more.
> >
> >
> >
> > Yeah it is possible create & attach http handlers to the chain inside
> > your deployment processor, same for auth mechanisms.
> > There are many subsystems that already do exactly this.
> 
> Awesome. Ok, that's all I needed.  I'll search the codebase.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From bburke at redhat.com  Sun Feb  9 10:38:31 2014
From: bburke at redhat.com (Bill Burke)
Date: Sun, 09 Feb 2014 10:38:31 -0500
Subject: [undertow-dev] accessing msc services
In-Reply-To: <818173510.2984.1391829699000.JavaMail.zimbra@redhat.com>
References: <52F522A4.7020201@redhat.com>
	<CAMquZP6T5QT6ArHoMQ0bT5=May28A=amv2_1x3GhnNoEjZaTMg@mail.gmail.com>
	<52F5473B.2060609@redhat.com>
	<CAMquZP5mfytZ1=q6aR9yO-Wmr2H_FgSeyjYDDxWrU9DtZ1VOTQ@mail.gmail.com>
	<52F54BC2.2090901@redhat.com>
	<818173510.2984.1391829699000.JavaMail.zimbra@redhat.com>
Message-ID: <52F7A0F7.7070406@redhat.com>

Thanks.

For a EAP/AS7 IIRC, JBossWeb only exposed Metadata, so I'd have to use a 
static service registry pattern or something?  Anybody know?

On 2/7/2014 10:21 PM, Stuart Douglas wrote:
> To save you looking the relevant class is org.wildfly.extension.undertow.deployment.UndertowAttachments.
>
> Stuart
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Toma? Cerar" <tomaz.cerar at gmail.com>
>> Cc: undertow-dev at lists.jboss.org
>> Sent: Friday, 7 February, 2014 11:10:26 PM
>> Subject: Re: [undertow-dev] accessing msc services
>>
>>
>>
>> On 2/7/2014 3:53 PM, Toma? Cerar wrote:
>>>
>>> On Fri, Feb 7, 2014 at 9:51 PM, Bill Burke <bburke at redhat.com
>>> <mailto:bburke at redhat.com>> wrote:
>>>
>>>      I just need a reference to this service as it contains config
>>>      information that is stored in the subsystem (standalone.xml, sorry
>>>      if I'm confusing the terminology).  Don't care where or when the
>>>      Undertow Handler gets this referenc(deploy time or runtime).
>>>
>>>      Is it possible to create HttpHandler instances in a deployment
>>>      processor and attach them to the WAR deployment?  What about
>>>      AuthMechanisms?  I guess I should dive into the undertow subsystem a
>>>      bit more.
>>>
>>>
>>>
>>> Yeah it is possible create & attach http handlers to the chain inside
>>> your deployment processor, same for auth mechanisms.
>>> There are many subsystems that already do exactly this.
>>
>> Awesome. Ok, that's all I needed.  I'll search the codebase.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From sdouglas at redhat.com  Tue Feb 11 01:44:18 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 11 Feb 2014 01:44:18 -0500 (EST)
Subject: [undertow-dev] accessing msc services
In-Reply-To: <52F7A0F7.7070406@redhat.com>
References: <52F522A4.7020201@redhat.com>
	<CAMquZP6T5QT6ArHoMQ0bT5=May28A=amv2_1x3GhnNoEjZaTMg@mail.gmail.com>
	<52F5473B.2060609@redhat.com>
	<CAMquZP5mfytZ1=q6aR9yO-Wmr2H_FgSeyjYDDxWrU9DtZ1VOTQ@mail.gmail.com>
	<52F54BC2.2090901@redhat.com>
	<818173510.2984.1391829699000.JavaMail.zimbra@redhat.com>
	<52F7A0F7.7070406@redhat.com>
Message-ID: <1928894359.863954.1392101058211.JavaMail.zimbra@redhat.com>

What information are you actually after? Undertow still uses the same metadata, but it also looks at some additional attachments when it is building the deployment. 

Something you could do to avoid the static service registry is just pass the ServiceRegistry that you can get in a DeploymentUnitProcessor to the HandlerWrappers constructor, and add the service name to you are after to the attachment org.jboss.as.server.deployment.Attachments#WEB_DEPENDENCIES.

This will allow you to look up the service in the handler wrapper, and adding it to the dependencies list means that it will definitely be up by that time.

Stuart

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: "Toma? Cerar" <tomaz.cerar at gmail.com>, undertow-dev at lists.jboss.org
> Sent: Sunday, 9 February, 2014 9:08:31 PM
> Subject: Re: [undertow-dev] accessing msc services
> 
> Thanks.
> 
> For a EAP/AS7 IIRC, JBossWeb only exposed Metadata, so I'd have to use a
> static service registry pattern or something?  Anybody know?
> 
> On 2/7/2014 10:21 PM, Stuart Douglas wrote:
> > To save you looking the relevant class is
> > org.wildfly.extension.undertow.deployment.UndertowAttachments.
> >
> > Stuart
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Toma? Cerar" <tomaz.cerar at gmail.com>
> >> Cc: undertow-dev at lists.jboss.org
> >> Sent: Friday, 7 February, 2014 11:10:26 PM
> >> Subject: Re: [undertow-dev] accessing msc services
> >>
> >>
> >>
> >> On 2/7/2014 3:53 PM, Toma? Cerar wrote:
> >>>
> >>> On Fri, Feb 7, 2014 at 9:51 PM, Bill Burke <bburke at redhat.com
> >>> <mailto:bburke at redhat.com>> wrote:
> >>>
> >>>      I just need a reference to this service as it contains config
> >>>      information that is stored in the subsystem (standalone.xml, sorry
> >>>      if I'm confusing the terminology).  Don't care where or when the
> >>>      Undertow Handler gets this referenc(deploy time or runtime).
> >>>
> >>>      Is it possible to create HttpHandler instances in a deployment
> >>>      processor and attach them to the WAR deployment?  What about
> >>>      AuthMechanisms?  I guess I should dive into the undertow subsystem a
> >>>      bit more.
> >>>
> >>>
> >>>
> >>> Yeah it is possible create & attach http handlers to the chain inside
> >>> your deployment processor, same for auth mechanisms.
> >>> There are many subsystems that already do exactly this.
> >>
> >> Awesome. Ok, that's all I needed.  I'll search the codebase.
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> undertow-dev mailing list
> >> undertow-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 


From bburke at redhat.com  Tue Feb 11 09:48:19 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 11 Feb 2014 09:48:19 -0500
Subject: [undertow-dev] accessing msc services
In-Reply-To: <1928894359.863954.1392101058211.JavaMail.zimbra@redhat.com>
References: <52F522A4.7020201@redhat.com>
	<CAMquZP6T5QT6ArHoMQ0bT5=May28A=amv2_1x3GhnNoEjZaTMg@mail.gmail.com>
	<52F5473B.2060609@redhat.com>
	<CAMquZP5mfytZ1=q6aR9yO-Wmr2H_FgSeyjYDDxWrU9DtZ1VOTQ@mail.gmail.com>
	<52F54BC2.2090901@redhat.com>
	<818173510.2984.1391829699000.JavaMail.zimbra@redhat.com>
	<52F7A0F7.7070406@redhat.com>
	<1928894359.863954.1392101058211.JavaMail.zimbra@redhat.com>
Message-ID: <52FA3833.1040503@redhat.com>

looking to have an handler notified when subsystem metadata is modified. 
  A redeploy won't work in all scenarios.

On 2/11/2014 1:44 AM, Stuart Douglas wrote:
> What information are you actually after? Undertow still uses the same metadata, but it also looks at some additional attachments when it is building the deployment.
>
> Something you could do to avoid the static service registry is just pass the ServiceRegistry that you can get in a DeploymentUnitProcessor to the HandlerWrappers constructor, and add the service name to you are after to the attachment org.jboss.as.server.deployment.Attachments#WEB_DEPENDENCIES.
>
> This will allow you to look up the service in the handler wrapper, and adding it to the dependencies list means that it will definitely be up by that time.
>
> Stuart
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stuart Douglas" <sdouglas at redhat.com>
>> Cc: "Toma? Cerar" <tomaz.cerar at gmail.com>, undertow-dev at lists.jboss.org
>> Sent: Sunday, 9 February, 2014 9:08:31 PM
>> Subject: Re: [undertow-dev] accessing msc services
>>
>> Thanks.
>>
>> For a EAP/AS7 IIRC, JBossWeb only exposed Metadata, so I'd have to use a
>> static service registry pattern or something?  Anybody know?
>>
>> On 2/7/2014 10:21 PM, Stuart Douglas wrote:
>>> To save you looking the relevant class is
>>> org.wildfly.extension.undertow.deployment.UndertowAttachments.
>>>
>>> Stuart
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Toma? Cerar" <tomaz.cerar at gmail.com>
>>>> Cc: undertow-dev at lists.jboss.org
>>>> Sent: Friday, 7 February, 2014 11:10:26 PM
>>>> Subject: Re: [undertow-dev] accessing msc services
>>>>
>>>>
>>>>
>>>> On 2/7/2014 3:53 PM, Toma? Cerar wrote:
>>>>>
>>>>> On Fri, Feb 7, 2014 at 9:51 PM, Bill Burke <bburke at redhat.com
>>>>> <mailto:bburke at redhat.com>> wrote:
>>>>>
>>>>>       I just need a reference to this service as it contains config
>>>>>       information that is stored in the subsystem (standalone.xml, sorry
>>>>>       if I'm confusing the terminology).  Don't care where or when the
>>>>>       Undertow Handler gets this referenc(deploy time or runtime).
>>>>>
>>>>>       Is it possible to create HttpHandler instances in a deployment
>>>>>       processor and attach them to the WAR deployment?  What about
>>>>>       AuthMechanisms?  I guess I should dive into the undertow subsystem a
>>>>>       bit more.
>>>>>
>>>>>
>>>>>
>>>>> Yeah it is possible create & attach http handlers to the chain inside
>>>>> your deployment processor, same for auth mechanisms.
>>>>> There are many subsystems that already do exactly this.
>>>>
>>>> Awesome. Ok, that's all I needed.  I'll search the codebase.
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From tomaz.cerar at gmail.com  Tue Feb 11 09:52:53 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 11 Feb 2014 15:52:53 +0100
Subject: [undertow-dev] accessing msc services
In-Reply-To: <52FA3833.1040503@redhat.com>
References: <52F522A4.7020201@redhat.com>
	<CAMquZP6T5QT6ArHoMQ0bT5=May28A=amv2_1x3GhnNoEjZaTMg@mail.gmail.com>
	<52F5473B.2060609@redhat.com>
	<CAMquZP5mfytZ1=q6aR9yO-Wmr2H_FgSeyjYDDxWrU9DtZ1VOTQ@mail.gmail.com>
	<52F54BC2.2090901@redhat.com>
	<818173510.2984.1391829699000.JavaMail.zimbra@redhat.com>
	<52F7A0F7.7070406@redhat.com>
	<1928894359.863954.1392101058211.JavaMail.zimbra@redhat.com>
	<52FA3833.1040503@redhat.com>
Message-ID: <CAMquZP4USMZzmdA=B+stY2cUqqQ1wPy7bFXQUtPm5jfxHvmRYg@mail.gmail.com>

what do you consider for subsystem metadata? and is this your subsystem or
undertow one?


On Tue, Feb 11, 2014 at 3:48 PM, Bill Burke <bburke at redhat.com> wrote:

> looking to have an handler notified when subsystem metadata is modified.
>  A redeploy won't work in all scenarios.
>
>
> On 2/11/2014 1:44 AM, Stuart Douglas wrote:
>
>> What information are you actually after? Undertow still uses the same
>> metadata, but it also looks at some additional attachments when it is
>> building the deployment.
>>
>> Something you could do to avoid the static service registry is just pass
>> the ServiceRegistry that you can get in a DeploymentUnitProcessor to the
>> HandlerWrappers constructor, and add the service name to you are after to
>> the attachment org.jboss.as.server.deployment.Attachments#WEB_
>> DEPENDENCIES.
>>
>> This will allow you to look up the service in the handler wrapper, and
>> adding it to the dependencies list means that it will definitely be up by
>> that time.
>>
>> Stuart
>>
>> ----- Original Message -----
>>
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Stuart Douglas" <sdouglas at redhat.com>
>>> Cc: "Toma? Cerar" <tomaz.cerar at gmail.com>, undertow-dev at lists.jboss.org
>>> Sent: Sunday, 9 February, 2014 9:08:31 PM
>>> Subject: Re: [undertow-dev] accessing msc services
>>>
>>> Thanks.
>>>
>>> For a EAP/AS7 IIRC, JBossWeb only exposed Metadata, so I'd have to use a
>>> static service registry pattern or something?  Anybody know?
>>>
>>> On 2/7/2014 10:21 PM, Stuart Douglas wrote:
>>>
>>>> To save you looking the relevant class is
>>>> org.wildfly.extension.undertow.deployment.UndertowAttachments.
>>>>
>>>> Stuart
>>>>
>>>> ----- Original Message -----
>>>>
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: "Toma? Cerar" <tomaz.cerar at gmail.com>
>>>>> Cc: undertow-dev at lists.jboss.org
>>>>> Sent: Friday, 7 February, 2014 11:10:26 PM
>>>>> Subject: Re: [undertow-dev] accessing msc services
>>>>>
>>>>>
>>>>>
>>>>> On 2/7/2014 3:53 PM, Toma? Cerar wrote:
>>>>>
>>>>>>
>>>>>> On Fri, Feb 7, 2014 at 9:51 PM, Bill Burke <bburke at redhat.com
>>>>>> <mailto:bburke at redhat.com>> wrote:
>>>>>>
>>>>>>       I just need a reference to this service as it contains config
>>>>>>       information that is stored in the subsystem (standalone.xml,
>>>>>> sorry
>>>>>>       if I'm confusing the terminology).  Don't care where or when the
>>>>>>       Undertow Handler gets this referenc(deploy time or runtime).
>>>>>>
>>>>>>       Is it possible to create HttpHandler instances in a deployment
>>>>>>       processor and attach them to the WAR deployment?  What about
>>>>>>       AuthMechanisms?  I guess I should dive into the undertow
>>>>>> subsystem a
>>>>>>       bit more.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yeah it is possible create & attach http handlers to the chain inside
>>>>>> your deployment processor, same for auth mechanisms.
>>>>>> There are many subsystems that already do exactly this.
>>>>>>
>>>>>
>>>>> Awesome. Ok, that's all I needed.  I'll search the codebase.
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>> _______________________________________________
>>>>> undertow-dev mailing list
>>>>> undertow-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>
>>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>>>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140211/a10e0d10/attachment.html 

From bburke at redhat.com  Tue Feb 11 09:54:22 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 11 Feb 2014 09:54:22 -0500
Subject: [undertow-dev] accessing msc services
In-Reply-To: <CAMquZP4USMZzmdA=B+stY2cUqqQ1wPy7bFXQUtPm5jfxHvmRYg@mail.gmail.com>
References: <52F522A4.7020201@redhat.com>	<CAMquZP6T5QT6ArHoMQ0bT5=May28A=amv2_1x3GhnNoEjZaTMg@mail.gmail.com>	<52F5473B.2060609@redhat.com>	<CAMquZP5mfytZ1=q6aR9yO-Wmr2H_FgSeyjYDDxWrU9DtZ1VOTQ@mail.gmail.com>	<52F54BC2.2090901@redhat.com>	<818173510.2984.1391829699000.JavaMail.zimbra@redhat.com>	<52F7A0F7.7070406@redhat.com>	<1928894359.863954.1392101058211.JavaMail.zimbra@redhat.com>	<52FA3833.1040503@redhat.com>
	<CAMquZP4USMZzmdA=B+stY2cUqqQ1wPy7bFXQUtPm5jfxHvmRYg@mail.gmail.com>
Message-ID: <52FA399E.4020605@redhat.com>

Ours, not undertow.

On 2/11/2014 9:52 AM, Toma? Cerar wrote:
> what do you consider for subsystem metadata? and is this your subsystem
> or undertow one?
>
>
> On Tue, Feb 11, 2014 at 3:48 PM, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>     looking to have an handler notified when subsystem metadata is
>     modified.  A redeploy won't work in all scenarios.
>
>
>     On 2/11/2014 1:44 AM, Stuart Douglas wrote:
>
>         What information are you actually after? Undertow still uses the
>         same metadata, but it also looks at some additional attachments
>         when it is building the deployment.
>
>         Something you could do to avoid the static service registry is
>         just pass the ServiceRegistry that you can get in a
>         DeploymentUnitProcessor to the HandlerWrappers constructor, and
>         add the service name to you are after to the attachment
>         org.jboss.as.server.__deployment.Attachments#WEB___DEPENDENCIES.
>
>         This will allow you to look up the service in the handler
>         wrapper, and adding it to the dependencies list means that it
>         will definitely be up by that time.
>
>         Stuart
>
>         ----- Original Message -----
>
>             From: "Bill Burke" <bburke at redhat.com
>             <mailto:bburke at redhat.com>>
>             To: "Stuart Douglas" <sdouglas at redhat.com
>             <mailto:sdouglas at redhat.com>>
>             Cc: "Toma? Cerar" <tomaz.cerar at gmail.com
>             <mailto:tomaz.cerar at gmail.com>>,
>             undertow-dev at lists.jboss.org
>             <mailto:undertow-dev at lists.jboss.org>
>             Sent: Sunday, 9 February, 2014 9:08:31 PM
>             Subject: Re: [undertow-dev] accessing msc services
>
>             Thanks.
>
>             For a EAP/AS7 IIRC, JBossWeb only exposed Metadata, so I'd
>             have to use a
>             static service registry pattern or something?  Anybody know?
>
>             On 2/7/2014 10:21 PM, Stuart Douglas wrote:
>
>                 To save you looking the relevant class is
>                 org.wildfly.extension.__undertow.deployment.__UndertowAttachments.
>
>                 Stuart
>
>                 ----- Original Message -----
>
>                     From: "Bill Burke" <bburke at redhat.com
>                     <mailto:bburke at redhat.com>>
>                     To: "Toma? Cerar" <tomaz.cerar at gmail.com
>                     <mailto:tomaz.cerar at gmail.com>>
>                     Cc: undertow-dev at lists.jboss.org
>                     <mailto:undertow-dev at lists.jboss.org>
>                     Sent: Friday, 7 February, 2014 11:10:26 PM
>                     Subject: Re: [undertow-dev] accessing msc services
>
>
>
>                     On 2/7/2014 3:53 PM, Toma? Cerar wrote:
>
>
>                         On Fri, Feb 7, 2014 at 9:51 PM, Bill Burke
>                         <bburke at redhat.com <mailto:bburke at redhat.com>
>                         <mailto:bburke at redhat.com
>                         <mailto:bburke at redhat.com>>> wrote:
>
>                                I just need a reference to this service
>                         as it contains config
>                                information that is stored in the
>                         subsystem (standalone.xml, sorry
>                                if I'm confusing the terminology).  Don't
>                         care where or when the
>                                Undertow Handler gets this
>                         referenc(deploy time or runtime).
>
>                                Is it possible to create HttpHandler
>                         instances in a deployment
>                                processor and attach them to the WAR
>                         deployment?  What about
>                                AuthMechanisms?  I guess I should dive
>                         into the undertow subsystem a
>                                bit more.
>
>
>
>                         Yeah it is possible create & attach http
>                         handlers to the chain inside
>                         your deployment processor, same for auth mechanisms.
>                         There are many subsystems that already do
>                         exactly this.
>
>
>                     Awesome. Ok, that's all I needed.  I'll search the
>                     codebase.
>
>                     --
>                     Bill Burke
>                     JBoss, a division of Red Hat
>                     http://bill.burkecentral.com
>                     _________________________________________________
>                     undertow-dev mailing list
>                     undertow-dev at lists.jboss.org
>                     <mailto:undertow-dev at lists.jboss.org>
>                     https://lists.jboss.org/__mailman/listinfo/undertow-dev
>                     <https://lists.jboss.org/mailman/listinfo/undertow-dev>
>
>
>             --
>             Bill Burke
>             JBoss, a division of Red Hat
>             http://bill.burkecentral.com
>
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From tomaz.cerar at gmail.com  Tue Feb 11 09:59:45 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 11 Feb 2014 15:59:45 +0100
Subject: [undertow-dev] accessing msc services
In-Reply-To: <52FA399E.4020605@redhat.com>
References: <52F522A4.7020201@redhat.com>
	<CAMquZP6T5QT6ArHoMQ0bT5=May28A=amv2_1x3GhnNoEjZaTMg@mail.gmail.com>
	<52F5473B.2060609@redhat.com>
	<CAMquZP5mfytZ1=q6aR9yO-Wmr2H_FgSeyjYDDxWrU9DtZ1VOTQ@mail.gmail.com>
	<52F54BC2.2090901@redhat.com>
	<818173510.2984.1391829699000.JavaMail.zimbra@redhat.com>
	<52F7A0F7.7070406@redhat.com>
	<1928894359.863954.1392101058211.JavaMail.zimbra@redhat.com>
	<52FA3833.1040503@redhat.com>
	<CAMquZP4USMZzmdA=B+stY2cUqqQ1wPy7bFXQUtPm5jfxHvmRYg@mail.gmail.com>
	<52FA399E.4020605@redhat.com>
Message-ID: <CAMquZP74q+TqZqbLdc7xzCNioA72b_+DHrV+Y1iEdqg2=OtZbw@mail.gmail.com>

so you probably mean, when some mgmt attribute / resource changes in your
subsystem how to pass that over to the handler.

Best way would be to have some msc service that holds the current data, and
you manipulate that service by :add/write-attribute handlers.
and your handlers have reference to that service, directly or indirectly is
different story.


On Tue, Feb 11, 2014 at 3:54 PM, Bill Burke <bburke at redhat.com> wrote:

> Ours, not undertow.
>
>
> On 2/11/2014 9:52 AM, Toma? Cerar wrote:
>
>> what do you consider for subsystem metadata? and is this your subsystem
>> or undertow one?
>>
>>
>> On Tue, Feb 11, 2014 at 3:48 PM, Bill Burke <bburke at redhat.com
>> <mailto:bburke at redhat.com>> wrote:
>>
>>     looking to have an handler notified when subsystem metadata is
>>     modified.  A redeploy won't work in all scenarios.
>>
>>
>>     On 2/11/2014 1:44 AM, Stuart Douglas wrote:
>>
>>         What information are you actually after? Undertow still uses the
>>         same metadata, but it also looks at some additional attachments
>>         when it is building the deployment.
>>
>>         Something you could do to avoid the static service registry is
>>         just pass the ServiceRegistry that you can get in a
>>         DeploymentUnitProcessor to the HandlerWrappers constructor, and
>>         add the service name to you are after to the attachment
>>         org.jboss.as.server.__deployment.Attachments#WEB___DEPENDENCIES.
>>
>>
>>         This will allow you to look up the service in the handler
>>         wrapper, and adding it to the dependencies list means that it
>>         will definitely be up by that time.
>>
>>         Stuart
>>
>>         ----- Original Message -----
>>
>>             From: "Bill Burke" <bburke at redhat.com
>>             <mailto:bburke at redhat.com>>
>>             To: "Stuart Douglas" <sdouglas at redhat.com
>>             <mailto:sdouglas at redhat.com>>
>>             Cc: "Toma? Cerar" <tomaz.cerar at gmail.com
>>             <mailto:tomaz.cerar at gmail.com>>,
>>             undertow-dev at lists.jboss.org
>>             <mailto:undertow-dev at lists.jboss.org>
>>
>>             Sent: Sunday, 9 February, 2014 9:08:31 PM
>>             Subject: Re: [undertow-dev] accessing msc services
>>
>>             Thanks.
>>
>>             For a EAP/AS7 IIRC, JBossWeb only exposed Metadata, so I'd
>>             have to use a
>>             static service registry pattern or something?  Anybody know?
>>
>>             On 2/7/2014 10:21 PM, Stuart Douglas wrote:
>>
>>                 To save you looking the relevant class is
>>                 org.wildfly.extension.__undertow.deployment.__
>> UndertowAttachments.
>>
>>
>>                 Stuart
>>
>>                 ----- Original Message -----
>>
>>                     From: "Bill Burke" <bburke at redhat.com
>>                     <mailto:bburke at redhat.com>>
>>                     To: "Toma? Cerar" <tomaz.cerar at gmail.com
>>                     <mailto:tomaz.cerar at gmail.com>>
>>                     Cc: undertow-dev at lists.jboss.org
>>                     <mailto:undertow-dev at lists.jboss.org>
>>
>>                     Sent: Friday, 7 February, 2014 11:10:26 PM
>>                     Subject: Re: [undertow-dev] accessing msc services
>>
>>
>>
>>                     On 2/7/2014 3:53 PM, Toma? Cerar wrote:
>>
>>
>>                         On Fri, Feb 7, 2014 at 9:51 PM, Bill Burke
>>                         <bburke at redhat.com <mailto:bburke at redhat.com>
>>                         <mailto:bburke at redhat.com
>>
>>                         <mailto:bburke at redhat.com>>> wrote:
>>
>>                                I just need a reference to this service
>>                         as it contains config
>>                                information that is stored in the
>>                         subsystem (standalone.xml, sorry
>>                                if I'm confusing the terminology).  Don't
>>                         care where or when the
>>                                Undertow Handler gets this
>>                         referenc(deploy time or runtime).
>>
>>                                Is it possible to create HttpHandler
>>                         instances in a deployment
>>                                processor and attach them to the WAR
>>                         deployment?  What about
>>                                AuthMechanisms?  I guess I should dive
>>                         into the undertow subsystem a
>>                                bit more.
>>
>>
>>
>>                         Yeah it is possible create & attach http
>>                         handlers to the chain inside
>>                         your deployment processor, same for auth
>> mechanisms.
>>                         There are many subsystems that already do
>>                         exactly this.
>>
>>
>>                     Awesome. Ok, that's all I needed.  I'll search the
>>                     codebase.
>>
>>                     --
>>                     Bill Burke
>>                     JBoss, a division of Red Hat
>>                     http://bill.burkecentral.com
>>                     _________________________________________________
>>
>>                     undertow-dev mailing list
>>                     undertow-dev at lists.jboss.org
>>                     <mailto:undertow-dev at lists.jboss.org>
>>                     https://lists.jboss.org/__
>> mailman/listinfo/undertow-dev
>>
>>                     <https://lists.jboss.org/
>> mailman/listinfo/undertow-dev>
>>
>>
>>             --
>>             Bill Burke
>>             JBoss, a division of Red Hat
>>             http://bill.burkecentral.com
>>
>>
>>     --
>>     Bill Burke
>>     JBoss, a division of Red Hat
>>     http://bill.burkecentral.com
>>
>>
>>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140211/d8d5ded3/attachment.html 

From bburke at redhat.com  Tue Feb 11 10:02:27 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 11 Feb 2014 10:02:27 -0500
Subject: [undertow-dev] accessing msc services
In-Reply-To: <CAMquZP74q+TqZqbLdc7xzCNioA72b_+DHrV+Y1iEdqg2=OtZbw@mail.gmail.com>
References: <52F522A4.7020201@redhat.com>	<CAMquZP6T5QT6ArHoMQ0bT5=May28A=amv2_1x3GhnNoEjZaTMg@mail.gmail.com>	<52F5473B.2060609@redhat.com>	<CAMquZP5mfytZ1=q6aR9yO-Wmr2H_FgSeyjYDDxWrU9DtZ1VOTQ@mail.gmail.com>	<52F54BC2.2090901@redhat.com>	<818173510.2984.1391829699000.JavaMail.zimbra@redhat.com>	<52F7A0F7.7070406@redhat.com>	<1928894359.863954.1392101058211.JavaMail.zimbra@redhat.com>	<52FA3833.1040503@redhat.com>	<CAMquZP4USMZzmdA=B+stY2cUqqQ1wPy7bFXQUtPm5jfxHvmRYg@mail.gmail.com>	<52FA399E.4020605@redhat.com>
	<CAMquZP74q+TqZqbLdc7xzCNioA72b_+DHrV+Y1iEdqg2=OtZbw@mail.gmail.com>
Message-ID: <52FA3B83.1050905@redhat.com>



On 2/11/2014 9:59 AM, Toma? Cerar wrote:
> so you probably mean, when some mgmt attribute / resource changes in
> your subsystem how to pass that over to the handler.
>
> Best way would be to have some msc service that holds the current data,
> and you manipulate that service by :add/write-attribute handlers.
> and your handlers have reference to that service, directly or indirectly
> is different story.
>

Yes, that was my original question.  How can an Undertow Handler or 
AuthMech get a reference to the MSC service? Which you guys answered.

I'm now trying to figure out the best way to do this on AS7/EAP6 with 
JBossWeb as its not as flexible (as awesome) as Undertow. :)

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From tomaz.cerar at gmail.com  Tue Feb 11 10:05:29 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 11 Feb 2014 16:05:29 +0100
Subject: [undertow-dev] accessing msc services
In-Reply-To: <52FA3B83.1050905@redhat.com>
References: <52F522A4.7020201@redhat.com>
	<CAMquZP6T5QT6ArHoMQ0bT5=May28A=amv2_1x3GhnNoEjZaTMg@mail.gmail.com>
	<52F5473B.2060609@redhat.com>
	<CAMquZP5mfytZ1=q6aR9yO-Wmr2H_FgSeyjYDDxWrU9DtZ1VOTQ@mail.gmail.com>
	<52F54BC2.2090901@redhat.com>
	<818173510.2984.1391829699000.JavaMail.zimbra@redhat.com>
	<52F7A0F7.7070406@redhat.com>
	<1928894359.863954.1392101058211.JavaMail.zimbra@redhat.com>
	<52FA3833.1040503@redhat.com>
	<CAMquZP4USMZzmdA=B+stY2cUqqQ1wPy7bFXQUtPm5jfxHvmRYg@mail.gmail.com>
	<52FA399E.4020605@redhat.com>
	<CAMquZP74q+TqZqbLdc7xzCNioA72b_+DHrV+Y1iEdqg2=OtZbw@mail.gmail.com>
	<52FA3B83.1050905@redhat.com>
Message-ID: <CAMquZP6C64f97GpTRY=_cqdRSP3O__TkRW2-bAUV7wXxxiQc_g@mail.gmail.com>

You could register tomcat valve and to pretty much similar things.


On Tue, Feb 11, 2014 at 4:02 PM, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 2/11/2014 9:59 AM, Toma? Cerar wrote:
>
>> so you probably mean, when some mgmt attribute / resource changes in
>> your subsystem how to pass that over to the handler.
>>
>> Best way would be to have some msc service that holds the current data,
>> and you manipulate that service by :add/write-attribute handlers.
>> and your handlers have reference to that service, directly or indirectly
>> is different story.
>>
>>
> Yes, that was my original question.  How can an Undertow Handler or
> AuthMech get a reference to the MSC service? Which you guys answered.
>
> I'm now trying to figure out the best way to do this on AS7/EAP6 with
> JBossWeb as its not as flexible (as awesome) as Undertow. :)
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140211/041757b8/attachment.html 

From bburke at redhat.com  Tue Feb 11 10:10:27 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 11 Feb 2014 10:10:27 -0500
Subject: [undertow-dev] accessing msc services
In-Reply-To: <CAMquZP6C64f97GpTRY=_cqdRSP3O__TkRW2-bAUV7wXxxiQc_g@mail.gmail.com>
References: <52F522A4.7020201@redhat.com>	<CAMquZP6T5QT6ArHoMQ0bT5=May28A=amv2_1x3GhnNoEjZaTMg@mail.gmail.com>	<52F5473B.2060609@redhat.com>	<CAMquZP5mfytZ1=q6aR9yO-Wmr2H_FgSeyjYDDxWrU9DtZ1VOTQ@mail.gmail.com>	<52F54BC2.2090901@redhat.com>	<818173510.2984.1391829699000.JavaMail.zimbra@redhat.com>	<52F7A0F7.7070406@redhat.com>	<1928894359.863954.1392101058211.JavaMail.zimbra@redhat.com>	<52FA3833.1040503@redhat.com>	<CAMquZP4USMZzmdA=B+stY2cUqqQ1wPy7bFXQUtPm5jfxHvmRYg@mail.gmail.com>	<52FA399E.4020605@redhat.com>	<CAMquZP74q+TqZqbLdc7xzCNioA72b_+DHrV+Y1iEdqg2=OtZbw@mail.gmail.com>	<52FA3B83.1050905@redhat.com>
	<CAMquZP6C64f97GpTRY=_cqdRSP3O__TkRW2-bAUV7wXxxiQc_g@mail.gmail.com>
Message-ID: <52FA3D63.2030301@redhat.com>

AFAICT, you can only specify a classname in ValveMetaData.  You can't 
actually instantiate the valve in the deployment processor.  Anyways. 
Apologies if this isn't the right list for this question.

On 2/11/2014 10:05 AM, Toma? Cerar wrote:
> You could register tomcat valve and to pretty much similar things.
>
>
> On Tue, Feb 11, 2014 at 4:02 PM, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>
>
>     On 2/11/2014 9:59 AM, Toma? Cerar wrote:
>
>         so you probably mean, when some mgmt attribute / resource changes in
>         your subsystem how to pass that over to the handler.
>
>         Best way would be to have some msc service that holds the
>         current data,
>         and you manipulate that service by :add/write-attribute handlers.
>         and your handlers have reference to that service, directly or
>         indirectly
>         is different story.
>
>
>     Yes, that was my original question.  How can an Undertow Handler or
>     AuthMech get a reference to the MSC service? Which you guys answered.
>
>     I'm now trying to figure out the best way to do this on AS7/EAP6
>     with JBossWeb as its not as flexible (as awesome) as Undertow. :)
>
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From tomaz.cerar at gmail.com  Tue Feb 11 10:27:13 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 11 Feb 2014 16:27:13 +0100
Subject: [undertow-dev] accessing msc services
In-Reply-To: <52FA3D63.2030301@redhat.com>
References: <52F522A4.7020201@redhat.com>
	<CAMquZP6T5QT6ArHoMQ0bT5=May28A=amv2_1x3GhnNoEjZaTMg@mail.gmail.com>
	<52F5473B.2060609@redhat.com>
	<CAMquZP5mfytZ1=q6aR9yO-Wmr2H_FgSeyjYDDxWrU9DtZ1VOTQ@mail.gmail.com>
	<52F54BC2.2090901@redhat.com>
	<818173510.2984.1391829699000.JavaMail.zimbra@redhat.com>
	<52F7A0F7.7070406@redhat.com>
	<1928894359.863954.1392101058211.JavaMail.zimbra@redhat.com>
	<52FA3833.1040503@redhat.com>
	<CAMquZP4USMZzmdA=B+stY2cUqqQ1wPy7bFXQUtPm5jfxHvmRYg@mail.gmail.com>
	<52FA399E.4020605@redhat.com>
	<CAMquZP74q+TqZqbLdc7xzCNioA72b_+DHrV+Y1iEdqg2=OtZbw@mail.gmail.com>
	<52FA3B83.1050905@redhat.com>
	<CAMquZP6C64f97GpTRY=_cqdRSP3O__TkRW2-bAUV7wXxxiQc_g@mail.gmail.com>
	<52FA3D63.2030301@redhat.com>
Message-ID: <CAMquZP7u-Hhy0GmtYCk-iD-Hq9zbrLDStF_iwHR9gtu5YpAxGQ@mail.gmail.com>

I don't know that code too well to really know, but what you have in mind
is valves defined by mgmt as in
subsystem=web/valve=myvalve:add(class-name=...)
I think it should be possible to add valve instance via web's msc service,
as i know gatein guys register valves directly.

How exactly and where i am not sure.


On Tue, Feb 11, 2014 at 4:10 PM, Bill Burke <bburke at redhat.com> wrote:

> AFAICT, you can only specify a classname in ValveMetaData.  You can't
> actually instantiate the valve in the deployment processor.  Anyways.
> Apologies if this isn't the right list for this question.
>
>
> On 2/11/2014 10:05 AM, Toma? Cerar wrote:
>
>> You could register tomcat valve and to pretty much similar things.
>>
>>
>> On Tue, Feb 11, 2014 at 4:02 PM, Bill Burke <bburke at redhat.com
>> <mailto:bburke at redhat.com>> wrote:
>>
>>
>>
>>     On 2/11/2014 9:59 AM, Toma? Cerar wrote:
>>
>>         so you probably mean, when some mgmt attribute / resource changes
>> in
>>         your subsystem how to pass that over to the handler.
>>
>>         Best way would be to have some msc service that holds the
>>         current data,
>>         and you manipulate that service by :add/write-attribute handlers.
>>         and your handlers have reference to that service, directly or
>>         indirectly
>>         is different story.
>>
>>
>>     Yes, that was my original question.  How can an Undertow Handler or
>>     AuthMech get a reference to the MSC service? Which you guys answered.
>>
>>     I'm now trying to figure out the best way to do this on AS7/EAP6
>>     with JBossWeb as its not as flexible (as awesome) as Undertow. :)
>>
>>
>>     --
>>     Bill Burke
>>     JBoss, a division of Red Hat
>>     http://bill.burkecentral.com
>>
>>
>>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140211/e6d24aae/attachment.html 

From wolfgang.knauf at gmx.de  Tue Feb 11 15:25:59 2014
From: wolfgang.knauf at gmx.de (Wolfgang Knauf)
Date: Tue, 11 Feb 2014 21:25:59 +0100
Subject: [undertow-dev] Class loader stacktraces on undeploy/deploy
Message-ID: <52FA8757.9080906@gmx.de>

Hi all,

I observe some warning stack traces when doing a 
".dodeploy"/".undeploy"./".dodeploy" cycle of an exploded JSF application.

A sample application is attached to 
https://community.jboss.org/message/856452
In this forum post, I reported a "locked manifest.mf" file error, so 
maybe the exceptions are related to this error.

To reproduce: extract the zip file content attached to the forum post to 
the "deployments" directory of a standalone WildFly CR1 server. Create a 
"KuchenZutatJSF.ear.dodeploy" marker file. After this first ".dodeploy", 
access the
URL http://localhost:8080/KuchenZutatJSFWeb/kuchenliste.faces (that 
should be enough to reproduce the error).

Then create ".undeploy" and ".dodeploy" marker files.

Now a warning stacktrace is in console, e.g. this one:

20:55:48,617 INFO  [javax.enterprise.resource.webcontainer.jsf.config] 
(MSC service thread 1-1) Mojarra 2.2.4-jbossorg-1 20131017-1524 f?r 
Kontext '/KuchenZutatJSFWeb' wird initialisiert.
20:55:48,977 WARN  [io.undertow.servlet] (MSC service thread 1-1) 
UT015008: Failed to load development mode persistent sessions: 
java.lang.ClassNotFoundException: 
pertyKeyses.component.UIComponent$ProertyKeysm from [Module 
"javax.faces.api:main" from local module loader @1087359 (finder: local 
module finder @1ccf342 (roots: 
C:\Temp\wildfly-8.0.0.CR1\modules,C:\Temp\wildfly-8.0.0.CR1\modules\system\layers\base))]
	at 
org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final]
	at 
org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) 
[jboss-modules.jar:1.3.0.Final]
	at 
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) 
[jboss-modules.jar:1.3.0.Final]
	at 
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) 
[jboss-modules.jar:1.3.0.Final]
	at 
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) 
[jboss-modules.jar:1.3.0.Final]
	at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_51]
	at java.lang.Class.forName(Unknown Source) [rt.jar:1.7.0_51]
	at 
org.jboss.marshalling.ModularClassResolver.resolveClass(ModularClassResolver.java:106)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:1006)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1243)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:184)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObjectArray(RiverUnmarshaller.java:1540)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadArray(RiverUnmarshaller.java:1579)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:330)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:184)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObjectArray(RiverUnmarshaller.java:1540)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadArray(RiverUnmarshaller.java:1579)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:330)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:184)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObjectArray(RiverUnmarshaller.java:1540)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadArray(RiverUnmarshaller.java:1579)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:330)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:184)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObjectArray(RiverUnmarshaller.java:1540)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadArray(RiverUnmarshaller.java:1579)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:330)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:184)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObjectArray(RiverUnmarshaller.java:1540)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadArray(RiverUnmarshaller.java:1579)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:330)
	at 
org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:153)
	at 
org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:139)
	at 
org.jboss.marshalling.MarshallerObjectInputStream.readObjectOverride(MarshallerObjectInputStream.java:57)
	at java.io.ObjectInputStream.readObject(Unknown Source) [rt.jar:1.7.0_51]
	at java.util.HashMap.readObject(Unknown Source) [rt.jar:1.7.0_51]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
[rt.jar:1.7.0_51]
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) 
[rt.jar:1.7.0_51]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) 
[rt.jar:1.7.0_51]
	at java.lang.reflect.Method.invoke(Unknown Source) [rt.jar:1.7.0_51]
	at 
org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:311)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1612)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1595)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1595)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1273)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
	at 
org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:153)
	at 
org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:139)
	at 
org.jboss.marshalling.MarshallerObjectInputStream.readObjectOverride(MarshallerObjectInputStream.java:57)
	at java.io.ObjectInputStream.readObject(Unknown Source) [rt.jar:1.7.0_51]
	at java.util.HashMap.readObject(Unknown Source) [rt.jar:1.7.0_51]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
[rt.jar:1.7.0_51]
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) 
[rt.jar:1.7.0_51]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) 
[rt.jar:1.7.0_51]
	at java.lang.reflect.Method.invoke(Unknown Source) [rt.jar:1.7.0_51]
	at 
org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:311)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1612)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1595)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1595)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1273)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
	at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
	at 
org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:45)
	at 
org.wildfly.extension.undertow.AbstractPersistentSessionManager.loadSessionAttributes(AbstractPersistentSessionManager.java:91)
	at 
io.undertow.servlet.handlers.SessionRestoringHandler.start(SessionRestoringHandler.java:56) 
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
	at 
io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:462) 
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
	at 
org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
	at 
org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:71)
	at 
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
	at 
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 
[rt.jar:1.7.0_51]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) 
[rt.jar:1.7.0_51]
	at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_51]

Another time, I saw this one:

20:50:24,811 WARN  [io.undertow.servlet] (MSC service thread 1-1) 
UT015008: Failed to load development mode persistent sessions: 
java.lang.IllegalArgumentException: No enum constant 
javax.faces.component.UIComponent.PropertyKeys.gsndinsp
     at java.lang.Enum.valueOf(Unknown Source) [rt.jar:1.7.0_51]
     at 
org.jboss.marshalling.river.RiverUnmarshaller.resolveEnumConstant(RiverUnmarshaller.java:1586)
     at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1330)

Is this related to the "locked files" issue, or is this an Undertow issue?


Best regards

Wolfgang Knauf

From tomaz.cerar at gmail.com  Tue Feb 11 20:05:32 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 12 Feb 2014 01:05:32 +0000
Subject: [undertow-dev] Class loader stacktraces on undeploy/deploy
In-Reply-To: <52FA8757.9080906@gmx.de>
References: <52FA8757.9080906@gmx.de>
Message-ID: <CAMquZP5ths21_dGxvoTcqSoTRjj8YEAKvBwRi0Mct4P+YKcHhQ@mail.gmail.com>

Hi,

try with newer code from wildfly master.

We removed persistent session from default configuration as it does not
work 100% yet.

--
tomaz


On Tue, Feb 11, 2014 at 8:25 PM, Wolfgang Knauf <wolfgang.knauf at gmx.de>wrote:

> Hi all,
>
> I observe some warning stack traces when doing a
> ".dodeploy"/".undeploy"./".dodeploy" cycle of an exploded JSF application.
>
> A sample application is attached to
> https://community.jboss.org/message/856452
> In this forum post, I reported a "locked manifest.mf" file error, so
> maybe the exceptions are related to this error.
>
> To reproduce: extract the zip file content attached to the forum post to
> the "deployments" directory of a standalone WildFly CR1 server. Create a
> "KuchenZutatJSF.ear.dodeploy" marker file. After this first ".dodeploy",
> access the
> URL http://localhost:8080/KuchenZutatJSFWeb/kuchenliste.faces (that
> should be enough to reproduce the error).
>
> Then create ".undeploy" and ".dodeploy" marker files.
>
> Now a warning stacktrace is in console, e.g. this one:
>
> 20:55:48,617 INFO  [javax.enterprise.resource.webcontainer.jsf.config]
> (MSC service thread 1-1) Mojarra 2.2.4-jbossorg-1 20131017-1524 f?r
> Kontext '/KuchenZutatJSFWeb' wird initialisiert.
> 20:55:48,977 WARN  [io.undertow.servlet] (MSC service thread 1-1)
> UT015008: Failed to load development mode persistent sessions:
> java.lang.ClassNotFoundException:
> pertyKeyses.component.UIComponent$ProertyKeysm from [Module
> "javax.faces.api:main" from local module loader @1087359 (finder: local
> module finder @1ccf342 (roots:
>
> C:\Temp\wildfly-8.0.0.CR1\modules,C:\Temp\wildfly-8.0.0.CR1\modules\system\layers\base))]
>         at
> org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197)
> [jboss-modules.jar:1.3.0.Final]
>         at
>
> org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443)
> [jboss-modules.jar:1.3.0.Final]
>         at
>
> org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431)
> [jboss-modules.jar:1.3.0.Final]
>         at
>
> org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373)
> [jboss-modules.jar:1.3.0.Final]
>         at
>
> org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118)
> [jboss-modules.jar:1.3.0.Final]
>         at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_51]
>         at java.lang.Class.forName(Unknown Source) [rt.jar:1.7.0_51]
>         at
>
> org.jboss.marshalling.ModularClassResolver.resolveClass(ModularClassResolver.java:106)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:1006)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1243)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:184)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadObjectArray(RiverUnmarshaller.java:1540)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadArray(RiverUnmarshaller.java:1579)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:330)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:184)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadObjectArray(RiverUnmarshaller.java:1540)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadArray(RiverUnmarshaller.java:1579)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:330)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:184)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadObjectArray(RiverUnmarshaller.java:1540)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadArray(RiverUnmarshaller.java:1579)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:330)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:184)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadObjectArray(RiverUnmarshaller.java:1540)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadArray(RiverUnmarshaller.java:1579)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:330)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:184)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadObjectArray(RiverUnmarshaller.java:1540)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadArray(RiverUnmarshaller.java:1579)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:330)
>         at
>
> org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:153)
>         at
>
> org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:139)
>         at
>
> org.jboss.marshalling.MarshallerObjectInputStream.readObjectOverride(MarshallerObjectInputStream.java:57)
>         at java.io.ObjectInputStream.readObject(Unknown Source)
> [rt.jar:1.7.0_51]
>         at java.util.HashMap.readObject(Unknown Source) [rt.jar:1.7.0_51]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.7.0_51]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> [rt.jar:1.7.0_51]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> [rt.jar:1.7.0_51]
>         at java.lang.reflect.Method.invoke(Unknown Source)
> [rt.jar:1.7.0_51]
>         at
>
> org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:311)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1612)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1595)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1595)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1273)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
>         at
>
> org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:153)
>         at
>
> org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:139)
>         at
>
> org.jboss.marshalling.MarshallerObjectInputStream.readObjectOverride(MarshallerObjectInputStream.java:57)
>         at java.io.ObjectInputStream.readObject(Unknown Source)
> [rt.jar:1.7.0_51]
>         at java.util.HashMap.readObject(Unknown Source) [rt.jar:1.7.0_51]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.7.0_51]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> [rt.jar:1.7.0_51]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> [rt.jar:1.7.0_51]
>         at java.lang.reflect.Method.invoke(Unknown Source)
> [rt.jar:1.7.0_51]
>         at
>
> org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:311)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1612)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1595)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1595)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1273)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
>         at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
>         at
>
> org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:45)
>         at
>
> org.wildfly.extension.undertow.AbstractPersistentSessionManager.loadSessionAttributes(AbstractPersistentSessionManager.java:91)
>         at
>
> io.undertow.servlet.handlers.SessionRestoringHandler.start(SessionRestoringHandler.java:56)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at
>
> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:462)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at
>
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
>         at
>
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:71)
>         at
>
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>         at
>
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> Source)
> [rt.jar:1.7.0_51]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source)
> [rt.jar:1.7.0_51]
>         at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_51]
>
> Another time, I saw this one:
>
> 20:50:24,811 WARN  [io.undertow.servlet] (MSC service thread 1-1)
> UT015008: Failed to load development mode persistent sessions:
> java.lang.IllegalArgumentException: No enum constant
> javax.faces.component.UIComponent.PropertyKeys.gsndinsp
>      at java.lang.Enum.valueOf(Unknown Source) [rt.jar:1.7.0_51]
>      at
>
> org.jboss.marshalling.river.RiverUnmarshaller.resolveEnumConstant(RiverUnmarshaller.java:1586)
>      at
>
> org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1330)
>
> Is this related to the "locked files" issue, or is this an Undertow issue?
>
>
> Best regards
>
> Wolfgang Knauf
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140212/0e73cbd0/attachment-0001.html 

From wolfgang.knauf at gmx.de  Wed Feb 12 16:11:27 2014
From: wolfgang.knauf at gmx.de (Wolfgang Knauf)
Date: Wed, 12 Feb 2014 22:11:27 +0100
Subject: [undertow-dev] Class loader stacktraces on undeploy/deploy
In-Reply-To: <CAMquZP5ths21_dGxvoTcqSoTRjj8YEAKvBwRi0Mct4P+YKcHhQ@mail.gmail.com>
References: <52FA8757.9080906@gmx.de>
	<CAMquZP5ths21_dGxvoTcqSoTRjj8YEAKvBwRi0Mct4P+YKcHhQ@mail.gmail.com>
Message-ID: <52FBE37F.5000606@gmx.de>

Thanks, I verified it with WF8 Final and the error is gone.

Shouldn't persisted sessions be removed when the app is undeployed?

Best regards

Wolfgang

-------- Original-Nachricht --------
Betreff: Re: [undertow-dev] Class loader stacktraces on undeploy/deploy
Von: Toma? Cerar <tomaz.cerar at gmail.com>
An: Wolfgang Knauf <wolfgang.knauf at gmx.de>
Kopie (CC): "undertow-dev at lists.jboss.org" <undertow-dev at lists.jboss.org>
Datum: 12.02.2014 02:05

> Hi,
>
> try with newer code from wildfly master.
>
> We removed persistent session from default configuration as it does not
> work 100% yet.
>
> --
> tomaz
>
>
> On Tue, Feb 11, 2014 at 8:25 PM, Wolfgang Knauf <wolfgang.knauf at gmx.de
> <mailto:wolfgang.knauf at gmx.de>> wrote:
>
>     Hi all,
>
>     I observe some warning stack traces when doing a
>     ".dodeploy"/".undeploy"./".dodeploy" cycle of an exploded JSF
>     application.
>
>     A sample application is attached to
>     https://community.jboss.org/message/856452
>     In this forum post, I reported a "locked manifest.mf" file error, so
>     maybe the exceptions are related to this error.
>
>     To reproduce: extract the zip file content attached to the forum post to
>     the "deployments" directory of a standalone WildFly CR1 server. Create a
>     "KuchenZutatJSF.ear.dodeploy" marker file. After this first ".dodeploy",
>     access the
>     URL http://localhost:8080/KuchenZutatJSFWeb/kuchenliste.faces (that
>     should be enough to reproduce the error).
>
>     Then create ".undeploy" and ".dodeploy" marker files.
>
>     Now a warning stacktrace is in console, e.g. this one:
>
>     20:55:48,617 INFO  [javax.enterprise.resource.webcontainer.jsf.config]
>     (MSC service thread 1-1) Mojarra 2.2.4-jbossorg-1 20131017-1524 f?r
>     Kontext '/KuchenZutatJSFWeb' wird initialisiert.
>     20:55:48,977 WARN  [io.undertow.servlet] (MSC service thread 1-1)
>     UT015008: Failed to load development mode persistent sessions:
>     java.lang.ClassNotFoundException:
>     pertyKeyses.component.UIComponent$ProertyKeysm from [Module
>     "javax.faces.api:main" from local module loader @1087359 (finder: local
>     module finder @1ccf342 (roots:
>     C:\Temp\wildfly-8.0.0.CR1\modules,C:\Temp\wildfly-8.0.0.CR1\modules\system\layers\base))]
>              at
>     org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197)
>     [jboss-modules.jar:1.3.0.Final]
>              at

From paulkmoore at gmail.com  Thu Feb 13 11:29:42 2014
From: paulkmoore at gmail.com (Paul K Moore)
Date: Thu, 13 Feb 2014 16:29:42 +0000
Subject: [undertow-dev] Security constraints and population of
	ServletSecurityInfo
Message-ID: <A1D12B59-F832-40C3-A6C7-E12372FDFEDD@gmail.com>

Hi all,

I am seeing some odd behaviour regarding security constraints.

If I add an @ServletSecurity annotation to a servlet, in the request the ServletSecurityInfo is (correctly) populated.

However, if I add (notionally) the same constraint in web.xml, the ServletSecurityInfo is *not* populated (it?s actually a null).

Is this the intended behaviour?

Many thanks

Paul

PS: Undertow version is Undertow 1.0.0.Final-SNAPSHOT, I?ve not moved to Wildfly 8.0.0 Final yet :)

From sdouglas at redhat.com  Thu Feb 13 21:40:10 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 13 Feb 2014 21:40:10 -0500 (EST)
Subject: [undertow-dev] Security constraints and population
	of	ServletSecurityInfo
In-Reply-To: <A1D12B59-F832-40C3-A6C7-E12372FDFEDD@gmail.com>
References: <A1D12B59-F832-40C3-A6C7-E12372FDFEDD@gmail.com>
Message-ID: <1841204369.3313411.1392345610820.JavaMail.zimbra@redhat.com>

When you say 'in the request the ServletSecurityInfo is (correctly) populated.' how are you actually checking this?

Stuart

----- Original Message -----
> From: "Paul K Moore" <paulkmoore at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Thursday, 13 February, 2014 9:59:42 PM
> Subject: [undertow-dev] Security constraints and population of	ServletSecurityInfo
> 
> Hi all,
> 
> I am seeing some odd behaviour regarding security constraints.
> 
> If I add an @ServletSecurity annotation to a servlet, in the request the
> ServletSecurityInfo is (correctly) populated.
> 
> However, if I add (notionally) the same constraint in web.xml, the
> ServletSecurityInfo is *not* populated (it?s actually a null).
> 
> Is this the intended behaviour?
> 
> Many thanks
> 
> Paul
> 
> PS: Undertow version is Undertow 1.0.0.Final-SNAPSHOT, I?ve not moved to
> Wildfly 8.0.0 Final yet :)
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 


From paulkmoore at gmail.com  Fri Feb 14 04:10:05 2014
From: paulkmoore at gmail.com (Paul K Moore)
Date: Fri, 14 Feb 2014 09:10:05 +0000
Subject: [undertow-dev] Security constraints and population of
	ServletSecurityInfo
In-Reply-To: <1841204369.3313411.1392345610820.JavaMail.zimbra@redhat.com>
References: <A1D12B59-F832-40C3-A6C7-E12372FDFEDD@gmail.com>
	<1841204369.3313411.1392345610820.JavaMail.zimbra@redhat.com>
Message-ID: <627C6408-6310-4491-8DCC-3E6E23C776A1@gmail.com>

Hi Stuart,

I?m checking it in the debugger, with a breakpoint in the doGet method of a (test) servlet.  

I then examine the request property at the following path:

	request.exchange.attachments and look for the ServletRequestContext, 

and from there the currentServlet.managedServlet.servletInfo.servletSecurityInfo

I?ve put a Gist here: https://gist.github.com/paulkmoore/8997728 so that you can see the servlet and web.xml.

The reason for the investigation is that I?m using JASPI which relies on ServletSecurityInfo being populated, as in the JASPIAuthenticationMechanism.isMandatory() method here.

Make sense?

Paul


On 14 Feb 2014, at 02:40, Stuart Douglas <sdouglas at redhat.com> wrote:

> When you say 'in the request the ServletSecurityInfo is (correctly) populated.' how are you actually checking this?
> 
> Stuart
> 
> ----- Original Message -----
>> From: "Paul K Moore" <paulkmoore at gmail.com>
>> To: undertow-dev at lists.jboss.org
>> Sent: Thursday, 13 February, 2014 9:59:42 PM
>> Subject: [undertow-dev] Security constraints and population of	ServletSecurityInfo
>> 
>> Hi all,
>> 
>> I am seeing some odd behaviour regarding security constraints.
>> 
>> If I add an @ServletSecurity annotation to a servlet, in the request the
>> ServletSecurityInfo is (correctly) populated.
>> 
>> However, if I add (notionally) the same constraint in web.xml, the
>> ServletSecurityInfo is *not* populated (it?s actually a null).
>> 
>> Is this the intended behaviour?
>> 
>> Many thanks
>> 
>> Paul
>> 
>> PS: Undertow version is Undertow 1.0.0.Final-SNAPSHOT, I?ve not moved to
>> Wildfly 8.0.0 Final yet :)
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140214/5c554bb4/attachment.html 

From sdouglas at redhat.com  Fri Feb 14 20:13:17 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 14 Feb 2014 20:13:17 -0500 (EST)
Subject: [undertow-dev] Security constraints and population of
 ServletSecurityInfo
In-Reply-To: <627C6408-6310-4491-8DCC-3E6E23C776A1@gmail.com>
References: <A1D12B59-F832-40C3-A6C7-E12372FDFEDD@gmail.com>
	<1841204369.3313411.1392345610820.JavaMail.zimbra@redhat.com>
	<627C6408-6310-4491-8DCC-3E6E23C776A1@gmail.com>
Message-ID: <903059698.3879966.1392426797435.JavaMail.zimbra@redhat.com>

I have filed this:

https://issues.jboss.org/browse/WFLY-2938

Basically this is a bug, we should not be using that attribute here as it only corresponds to constraints applied directly to the servlet, and not other path based constrains. The actual current constraint set is aggregated in the ServletRequestContext.

Fix is here: https://github.com/wildfly/wildfly/pull/5916

Stuart

----- Original Message -----
> From: "Paul K Moore" <paulkmoore at gmail.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Friday, 14 February, 2014 2:40:05 PM
> Subject: Re: [undertow-dev] Security constraints and population of ServletSecurityInfo
> 
> Hi Stuart,
> 
> I?m checking it in the debugger, with a breakpoint in the doGet method of a
> (test) servlet.
> 
> I then examine the request property at the following path:
> 
> 	request.exchange.attachments and look for the ServletRequestContext,
> 
> and from there the
> currentServlet.managedServlet.servletInfo.servletSecurityInfo
> 
> I?ve put a Gist here: https://gist.github.com/paulkmoore/8997728 so that you
> can see the servlet and web.xml.
> 
> The reason for the investigation is that I?m using JASPI which relies on
> ServletSecurityInfo being populated, as in the
> JASPIAuthenticationMechanism.isMandatory() method here.
> 
> Make sense?
> 
> Paul
> 
> 
> On 14 Feb 2014, at 02:40, Stuart Douglas <sdouglas at redhat.com> wrote:
> 
> > When you say 'in the request the ServletSecurityInfo is (correctly)
> > populated.' how are you actually checking this?
> > 
> > Stuart
> > 
> > ----- Original Message -----
> >> From: "Paul K Moore" <paulkmoore at gmail.com>
> >> To: undertow-dev at lists.jboss.org
> >> Sent: Thursday, 13 February, 2014 9:59:42 PM
> >> Subject: [undertow-dev] Security constraints and population of
> >> 	ServletSecurityInfo
> >> 
> >> Hi all,
> >> 
> >> I am seeing some odd behaviour regarding security constraints.
> >> 
> >> If I add an @ServletSecurity annotation to a servlet, in the request the
> >> ServletSecurityInfo is (correctly) populated.
> >> 
> >> However, if I add (notionally) the same constraint in web.xml, the
> >> ServletSecurityInfo is *not* populated (it?s actually a null).
> >> 
> >> Is this the intended behaviour?
> >> 
> >> Many thanks
> >> 
> >> Paul
> >> 
> >> PS: Undertow version is Undertow 1.0.0.Final-SNAPSHOT, I?ve not moved to
> >> Wildfly 8.0.0 Final yet :)
> >> _______________________________________________
> >> undertow-dev mailing list
> >> undertow-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >> 
> 
> 


From paulkmoore at gmail.com  Sun Feb 16 05:12:10 2014
From: paulkmoore at gmail.com (Paul K Moore)
Date: Sun, 16 Feb 2014 10:12:10 +0000
Subject: [undertow-dev] Security constraints and population of
	ServletSecurityInfo
In-Reply-To: <903059698.3879966.1392426797435.JavaMail.zimbra@redhat.com>
References: <A1D12B59-F832-40C3-A6C7-E12372FDFEDD@gmail.com>
	<1841204369.3313411.1392345610820.JavaMail.zimbra@redhat.com>
	<627C6408-6310-4491-8DCC-3E6E23C776A1@gmail.com>
	<903059698.3879966.1392426797435.JavaMail.zimbra@redhat.com>
Message-ID: <9CE0E6CA-6A35-4C38-A54F-BA533C9A1E27@gmail.com>

Hi Stuart,

Superb - thank you. 

I noticed that the build has failed on the pull request due to what looks like environmental reasons.  I?ll try a merge locally and report back.

Thanks again

Paul

On 15 Feb 2014, at 01:13, Stuart Douglas <sdouglas at redhat.com> wrote:

> I have filed this:
> 
> https://issues.jboss.org/browse/WFLY-2938
> 
> Basically this is a bug, we should not be using that attribute here as it only corresponds to constraints applied directly to the servlet, and not other path based constrains. The actual current constraint set is aggregated in the ServletRequestContext.
> 
> Fix is here: https://github.com/wildfly/wildfly/pull/5916
> 
> Stuart
> 
> ----- Original Message -----
>> From: "Paul K Moore" <paulkmoore at gmail.com>
>> To: "Stuart Douglas" <sdouglas at redhat.com>
>> Cc: undertow-dev at lists.jboss.org
>> Sent: Friday, 14 February, 2014 2:40:05 PM
>> Subject: Re: [undertow-dev] Security constraints and population of ServletSecurityInfo
>> 
>> Hi Stuart,
>> 
>> I?m checking it in the debugger, with a breakpoint in the doGet method of a
>> (test) servlet.
>> 
>> I then examine the request property at the following path:
>> 
>> 	request.exchange.attachments and look for the ServletRequestContext,
>> 
>> and from there the
>> currentServlet.managedServlet.servletInfo.servletSecurityInfo
>> 
>> I?ve put a Gist here: https://gist.github.com/paulkmoore/8997728 so that you
>> can see the servlet and web.xml.
>> 
>> The reason for the investigation is that I?m using JASPI which relies on
>> ServletSecurityInfo being populated, as in the
>> JASPIAuthenticationMechanism.isMandatory() method here.
>> 
>> Make sense?
>> 
>> Paul
>> 
>> 
>> On 14 Feb 2014, at 02:40, Stuart Douglas <sdouglas at redhat.com> wrote:
>> 
>>> When you say 'in the request the ServletSecurityInfo is (correctly)
>>> populated.' how are you actually checking this?
>>> 
>>> Stuart
>>> 
>>> ----- Original Message -----
>>>> From: "Paul K Moore" <paulkmoore at gmail.com>
>>>> To: undertow-dev at lists.jboss.org
>>>> Sent: Thursday, 13 February, 2014 9:59:42 PM
>>>> Subject: [undertow-dev] Security constraints and population of
>>>> 	ServletSecurityInfo
>>>> 
>>>> Hi all,
>>>> 
>>>> I am seeing some odd behaviour regarding security constraints.
>>>> 
>>>> If I add an @ServletSecurity annotation to a servlet, in the request the
>>>> ServletSecurityInfo is (correctly) populated.
>>>> 
>>>> However, if I add (notionally) the same constraint in web.xml, the
>>>> ServletSecurityInfo is *not* populated (it?s actually a null).
>>>> 
>>>> Is this the intended behaviour?
>>>> 
>>>> Many thanks
>>>> 
>>>> Paul
>>>> 
>>>> PS: Undertow version is Undertow 1.0.0.Final-SNAPSHOT, I?ve not moved to
>>>> Wildfly 8.0.0 Final yet :)
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>> 
>> 
>> 



From paulkmoore at gmail.com  Sun Feb 16 17:38:54 2014
From: paulkmoore at gmail.com (Paul K Moore)
Date: Sun, 16 Feb 2014 22:38:54 +0000
Subject: [undertow-dev] Security constraints and population of
	ServletSecurityInfo
In-Reply-To: <9CE0E6CA-6A35-4C38-A54F-BA533C9A1E27@gmail.com>
References: <A1D12B59-F832-40C3-A6C7-E12372FDFEDD@gmail.com>
	<1841204369.3313411.1392345610820.JavaMail.zimbra@redhat.com>
	<627C6408-6310-4491-8DCC-3E6E23C776A1@gmail.com>
	<903059698.3879966.1392426797435.JavaMail.zimbra@redhat.com>
	<9CE0E6CA-6A35-4C38-A54F-BA533C9A1E27@gmail.com>
Message-ID: <53C95751-DE1C-4CB3-BB1E-B7D323FB3480@gmail.com>

Stuart,

Just a quick follow-up, as promised.  I?ve merged your change locally, and all is working well.  

Thanks again for sorting :)

Paul

On 16 Feb 2014, at 10:12, Paul K Moore <paulkmoore at gmail.com> wrote:

> Hi Stuart,
> 
> Superb - thank you. 
> 
> I noticed that the build has failed on the pull request due to what looks like environmental reasons.  I?ll try a merge locally and report back.
> 
> Thanks again
> 
> Paul
> 
> On 15 Feb 2014, at 01:13, Stuart Douglas <sdouglas at redhat.com> wrote:
> 
>> I have filed this:
>> 
>> https://issues.jboss.org/browse/WFLY-2938
>> 
>> Basically this is a bug, we should not be using that attribute here as it only corresponds to constraints applied directly to the servlet, and not other path based constrains. The actual current constraint set is aggregated in the ServletRequestContext.
>> 
>> Fix is here: https://github.com/wildfly/wildfly/pull/5916
>> 
>> Stuart
>> 
>> ----- Original Message -----
>>> From: "Paul K Moore" <paulkmoore at gmail.com>
>>> To: "Stuart Douglas" <sdouglas at redhat.com>
>>> Cc: undertow-dev at lists.jboss.org
>>> Sent: Friday, 14 February, 2014 2:40:05 PM
>>> Subject: Re: [undertow-dev] Security constraints and population of ServletSecurityInfo
>>> 
>>> Hi Stuart,
>>> 
>>> I?m checking it in the debugger, with a breakpoint in the doGet method of a
>>> (test) servlet.
>>> 
>>> I then examine the request property at the following path:
>>> 
>>> 	request.exchange.attachments and look for the ServletRequestContext,
>>> 
>>> and from there the
>>> currentServlet.managedServlet.servletInfo.servletSecurityInfo
>>> 
>>> I?ve put a Gist here: https://gist.github.com/paulkmoore/8997728 so that you
>>> can see the servlet and web.xml.
>>> 
>>> The reason for the investigation is that I?m using JASPI which relies on
>>> ServletSecurityInfo being populated, as in the
>>> JASPIAuthenticationMechanism.isMandatory() method here.
>>> 
>>> Make sense?
>>> 
>>> Paul
>>> 
>>> 
>>> On 14 Feb 2014, at 02:40, Stuart Douglas <sdouglas at redhat.com> wrote:
>>> 
>>>> When you say 'in the request the ServletSecurityInfo is (correctly)
>>>> populated.' how are you actually checking this?
>>>> 
>>>> Stuart
>>>> 
>>>> ----- Original Message -----
>>>>> From: "Paul K Moore" <paulkmoore at gmail.com>
>>>>> To: undertow-dev at lists.jboss.org
>>>>> Sent: Thursday, 13 February, 2014 9:59:42 PM
>>>>> Subject: [undertow-dev] Security constraints and population of
>>>>> 	ServletSecurityInfo
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I am seeing some odd behaviour regarding security constraints.
>>>>> 
>>>>> If I add an @ServletSecurity annotation to a servlet, in the request the
>>>>> ServletSecurityInfo is (correctly) populated.
>>>>> 
>>>>> However, if I add (notionally) the same constraint in web.xml, the
>>>>> ServletSecurityInfo is *not* populated (it?s actually a null).
>>>>> 
>>>>> Is this the intended behaviour?
>>>>> 
>>>>> Many thanks
>>>>> 
>>>>> Paul
>>>>> 
>>>>> PS: Undertow version is Undertow 1.0.0.Final-SNAPSHOT, I?ve not moved to
>>>>> Wildfly 8.0.0 Final yet :)
>>>>> _______________________________________________
>>>>> undertow-dev mailing list
>>>>> undertow-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>> 
>>> 
>>> 
> 



From mikhail.tiamine at gmail.com  Mon Feb 17 04:33:41 2014
From: mikhail.tiamine at gmail.com (Mikhail Tyamin)
Date: Mon, 17 Feb 2014 11:33:41 +0200
Subject: [undertow-dev] what I do wrong?
Message-ID: <CAOKv2Z-ME8N3sV2bX0M7ENFm52Xd5=eMVk4FXrwz98vf3Aw4vQ@mail.gmail.com>

Hello guys,

could you help me a little bit with Undertow?

I follow all instructions in Undertown's poor documentation. So here is the
class :

public class HelloWorldServer {

    public static void main(String... args) {
        Undertow server = Undertow.builder()
                .addHttpListener(8080, "localhost")
                .setHandler(new HttpHandler() {
                    @Override
                    public void handleRequest(final HttpServerExchange
exchange) throws Exception {
                        if (exchange.isInIoThread()) {
                            System.out.println("Thread #" +
Thread.currentThread().getName() + " is I/O : handle this");
                            exchange.dispatch(this);
                            return;
                        }

                        //[1]
                        System.out.println("Thread #" +
Thread.currentThread().getName() + " Start waiting");
                        Thread.sleep(15000);
                        System.out.println("Thread #" +
Thread.currentThread().getName() + " Finish waiting");

                        System.out.println();


exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
                        exchange.getResponseSender().send("Hello world from
thread " + Thread.currentThread().getId());
                        //[2]
                    }
                }).build();

        server.start();
    }
}


When I start it and make three http get request simultaneously I can see
this output in console :

Thread #XNIO-1 I/O-1 is I/O : handle this
Thread #XNIO-1 task-1 Start waiting
Thread #XNIO-1 task-1 Finish waiting

Thread #XNIO-1 I/O-1 is I/O : handle this
Thread #XNIO-1 task-2 Start waiting
Thread #XNIO-1 task-2 Finish waiting

Thread #XNIO-1 I/O-1 is I/O : handle this
Thread #XNIO-1 task-3 Start waiting
Thread #XNIO-1 task-3 Finish waiting


I think that code beetween //[1] and //[2] should perform in separate
thread (and as we can see from the console it really does), but why the
main I/O thread are waiting and does not handle other requests?

So if my code is correct than it means that Undertow could handle one
request in time...

What I do wrong?

Best,
Mikhail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140217/44cca887/attachment.html 

From lsgroup at gmail.com  Mon Feb 17 14:38:58 2014
From: lsgroup at gmail.com (Lightspoke Discussion)
Date: Mon, 17 Feb 2014 11:38:58 -0800
Subject: [undertow-dev] Sharing session attributes in NonBlocking Handlers
	and Traditional Servlets
Message-ID: <CAL1VK-E82ao9r21ryMSd=3oUK4CA3_MtwptDqDLFAGpiYDg1xg@mail.gmail.com>

Hello,

Does anyone know how you might go about sharing session attributes between
a servlet and a non-blocking handler in the same project?

        InMemorySessionManager sessman = new
InMemorySessionManager(foundsessid);
        SessionAttachmentHandler sessattach = new
SessionAttachmentHandler(sessman, sessconf);
        SessionManager regsessman = sessattach.getSessionManager();

        Session session;
        session = sessman.getSession(exchange, sessconf);
        //returns null



        SessionCookieConfig sessconf = new SessionCookieConfig();
        String foundsessid = sessconf.findSessionId(exchange);
        session = regsessman.getSession(foundsessid);
        System.out.println("getsession by id ="+session );
        //returns null


        session = regsessman.createSession(exchange, sessconf);
        System.out.println("create session  ="+session );

        //returns a session - but ...

1. session attributes from servlet do not return its value and
2. session attributes across http requests do not persist in memory

Thanks in advance!




-- 
--
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140217/60884bae/attachment.html 

From sdouglas at redhat.com  Mon Feb 17 22:22:33 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 17 Feb 2014 22:22:33 -0500 (EST)
Subject: [undertow-dev] what I do wrong?
In-Reply-To: <CAOKv2Z-ME8N3sV2bX0M7ENFm52Xd5=eMVk4FXrwz98vf3Aw4vQ@mail.gmail.com>
References: <CAOKv2Z-ME8N3sV2bX0M7ENFm52Xd5=eMVk4FXrwz98vf3Aw4vQ@mail.gmail.com>
Message-ID: <964925076.4821756.1392693753296.JavaMail.zimbra@redhat.com>

Are you sure the requests are actually being made simultaneously? That code should definitely work.

Stuart


----- Original Message -----
> From: "Mikhail Tyamin" <mikhail.tiamine at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Monday, 17 February, 2014 3:03:41 PM
> Subject: [undertow-dev] what I do wrong?
> 
> Hello guys,
> 
> could you help me a little bit with Undertow?
> 
> I follow all instructions in Undertown's poor documentation. So here is the
> class :
> 
> public class HelloWorldServer {
> 
> public static void main(String... args) {
> Undertow server = Undertow.builder()
> .addHttpListener(8080, "localhost")
> .setHandler(new HttpHandler() {
> @Override
> public void handleRequest(final HttpServerExchange exchange) throws Exception
> {
> if (exchange.isInIoThread()) {
> System.out.println("Thread #" + Thread.currentThread().getName() + " is I/O :
> handle this");
> exchange.dispatch(this);
> return;
> }
> 
> //[1]
> System.out.println("Thread #" + Thread.currentThread().getName() + " Start
> waiting");
> Thread.sleep(15000);
> System.out.println("Thread #" + Thread.currentThread().getName() + " Finish
> waiting");
> 
> System.out.println();
> 
> exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
> exchange.getResponseSender().send("Hello world from thread " +
> Thread.currentThread().getId());
> //[2]
> }
> }).build();
> 
> server.start();
> }
> }
> 
> When I start it and make three http get request simultaneously I can see this
> output in console :
> 
> Thread #XNIO-1 I/O-1 is I/O : handle this
> Thread #XNIO-1 task-1 Start waiting
> Thread #XNIO-1 task-1 Finish waiting
> 
> Thread #XNIO-1 I/O-1 is I/O : handle this
> Thread #XNIO-1 task-2 Start waiting
> Thread #XNIO-1 task-2 Finish waiting
> 
> Thread #XNIO-1 I/O-1 is I/O : handle this
> Thread #XNIO-1 task-3 Start waiting
> Thread #XNIO-1 task-3 Finish waiting
> 
> 
> I think that code beetween //[1] and //[2] should perform in separate thread
> (and as we can see from the console it really does), but why the main I/O
> thread are waiting and does not handle other requests?
> 
> So if my code is correct than it means that Undertow could handle one request
> in time...
> 
> What I do wrong?
> 
> Best,
> Mikhail
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From mail.emersol at gmail.com  Mon Feb 17 04:55:36 2014
From: mail.emersol at gmail.com (EMERSOL Technologies)
Date: Mon, 17 Feb 2014 15:25:36 +0530
Subject: [undertow-dev] download link is broken
Message-ID: <CAPDN8sMYQrchQZqECU4HDGaTh+8Vwf-mK7xZeoz4UHz_md44cA@mail.gmail.com>

Hello WildFly / Undertow Team,

The download link for undertow is pointing at a wrong location.

http://undertow.io/downloads.html -> http://www.wildfly.org/download/

Its should be http://wildfly.org/downloads/

Best Regards,
ET.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140217/e10514bc/attachment.html 

From sdouglas at redhat.com  Mon Feb 17 22:27:57 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 17 Feb 2014 22:27:57 -0500 (EST)
Subject: [undertow-dev] Sharing session attributes in NonBlocking
 Handlers	and Traditional Servlets
In-Reply-To: <CAL1VK-E82ao9r21ryMSd=3oUK4CA3_MtwptDqDLFAGpiYDg1xg@mail.gmail.com>
References: <CAL1VK-E82ao9r21ryMSd=3oUK4CA3_MtwptDqDLFAGpiYDg1xg@mail.gmail.com>
Message-ID: <1827210399.4822231.1392694077935.JavaMail.zimbra@redhat.com>

Basically you need to use io.undertow.servlet.spec.ServletContextImpl#getSession(). 

If your handler is running after the initial servlet handler you can get this from the io.undertow.servlet.handlers.ServletRequestContext, which is attached to the exchange. 

If you are running before the initial handler you need to store a reference to the servlet context or the Deployment somewhere.

Servlet does not use SessionAttachmentHandler, because each servlet context can have its own session with its own settings, and multiple contexts can be involved in the same request if forward/include is used. As a result each servlet context has its own session manager, and manages it internally.

Stuart

----- Original Message -----
> From: "Lightspoke Discussion" <lsgroup at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Tuesday, 18 February, 2014 1:08:58 AM
> Subject: [undertow-dev] Sharing session attributes in NonBlocking Handlers	and Traditional Servlets
> 
> Hello,
> 
> Does anyone know how you might go about sharing session attributes between a
> servlet and a non-blocking handler in the same project?
> 
> InMemorySessionManager sessman = new InMemorySessionManager(foundsessid);
> SessionAttachmentHandler sessattach = new SessionAttachmentHandler(sessman,
> sessconf);
> SessionManager regsessman = sessattach.getSessionManager();
> Session session;
> session = sessman.getSession(exchange, sessconf);
> //returns null
> 
> 
> 
> SessionCookieConfig sessconf = new SessionCookieConfig();
> String foundsessid = sessconf.findSessionId(exchange);
> session = regsessman.getSession(foundsessid);
> System.out.println("getsession by id ="+session );
> //returns null
> 
> 
> session = regsessman.createSession(exchange, sessconf);
> System.out.println("create session ="+session );
> 
> //returns a session - but ...
> 
> 1. session attributes from servlet do not return its value and
> 2. session attributes across http requests do not persist in memory
> 
> Thanks in advance!
> 
> 
> 
> --
> --
> Mike
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From sdouglas at redhat.com  Mon Feb 17 22:28:23 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 17 Feb 2014 22:28:23 -0500 (EST)
Subject: [undertow-dev] download link is broken
In-Reply-To: <CAPDN8sMYQrchQZqECU4HDGaTh+8Vwf-mK7xZeoz4UHz_md44cA@mail.gmail.com>
References: <CAPDN8sMYQrchQZqECU4HDGaTh+8Vwf-mK7xZeoz4UHz_md44cA@mail.gmail.com>
Message-ID: <717605585.4822266.1392694103653.JavaMail.zimbra@redhat.com>

Thanks, I will fix this up.

Stuart

----- Original Message -----
> From: "EMERSOL Technologies" <mail.emersol at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Monday, 17 February, 2014 3:25:36 PM
> Subject: [undertow-dev] download link is broken
> 
> Hello WildFly / Undertow Team,
> 
> The download link for undertow is pointing at a wrong location.
> 
> http://undertow.io/downloads.html -> http://www.wildfly.org/download/
> 
> Its should be http://wildfly.org/downloads/
> 
> Best Regards,
> ET.
> 
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From mikhail.tiamine at gmail.com  Tue Feb 18 01:10:32 2014
From: mikhail.tiamine at gmail.com (Mikhail Tyamin)
Date: Tue, 18 Feb 2014 08:10:32 +0200
Subject: [undertow-dev] what I do wrong?
In-Reply-To: <964925076.4821756.1392693753296.JavaMail.zimbra@redhat.com>
References: <CAOKv2Z-ME8N3sV2bX0M7ENFm52Xd5=eMVk4FXrwz98vf3Aw4vQ@mail.gmail.com>
	<964925076.4821756.1392693753296.JavaMail.zimbra@redhat.com>
Message-ID: <CAOKv2Z-UuLq6HwDCQ1O0MfQ4gDJeFyGz84Enoi_anKd9iX4U5Q@mail.gmail.com>

Hi,

I am pretty sure, 15 sec. delay is enough to open additional browsers
windows ;-)

I try to run code with io.undertow:undertow-core:1.0.0.Final on mac with OS
X 10.9.1   with jdk 1.7.0_51.

So, could anybody reproduce this issue or give me feedback where is my
error?

Best,
Mikhail


2014-02-18 5:22 GMT+02:00 Stuart Douglas <sdouglas at redhat.com>:

> Are you sure the requests are actually being made simultaneously? That
> code should definitely work.
>
> Stuart
>
>
> ----- Original Message -----
> > From: "Mikhail Tyamin" <mikhail.tiamine at gmail.com>
> > To: undertow-dev at lists.jboss.org
> > Sent: Monday, 17 February, 2014 3:03:41 PM
> > Subject: [undertow-dev] what I do wrong?
> >
> > Hello guys,
> >
> > could you help me a little bit with Undertow?
> >
> > I follow all instructions in Undertown's poor documentation. So here is
> the
> > class :
> >
> > public class HelloWorldServer {
> >
> > public static void main(String... args) {
> > Undertow server = Undertow.builder()
> > .addHttpListener(8080, "localhost")
> > .setHandler(new HttpHandler() {
> > @Override
> > public void handleRequest(final HttpServerExchange exchange) throws
> Exception
> > {
> > if (exchange.isInIoThread()) {
> > System.out.println("Thread #" + Thread.currentThread().getName() + " is
> I/O :
> > handle this");
> > exchange.dispatch(this);
> > return;
> > }
> >
> > //[1]
> > System.out.println("Thread #" + Thread.currentThread().getName() + "
> Start
> > waiting");
> > Thread.sleep(15000);
> > System.out.println("Thread #" + Thread.currentThread().getName() + "
> Finish
> > waiting");
> >
> > System.out.println();
> >
> > exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
> > exchange.getResponseSender().send("Hello world from thread " +
> > Thread.currentThread().getId());
> > //[2]
> > }
> > }).build();
> >
> > server.start();
> > }
> > }
> >
> > When I start it and make three http get request simultaneously I can see
> this
> > output in console :
> >
> > Thread #XNIO-1 I/O-1 is I/O : handle this
> > Thread #XNIO-1 task-1 Start waiting
> > Thread #XNIO-1 task-1 Finish waiting
> >
> > Thread #XNIO-1 I/O-1 is I/O : handle this
> > Thread #XNIO-1 task-2 Start waiting
> > Thread #XNIO-1 task-2 Finish waiting
> >
> > Thread #XNIO-1 I/O-1 is I/O : handle this
> > Thread #XNIO-1 task-3 Start waiting
> > Thread #XNIO-1 task-3 Finish waiting
> >
> >
> > I think that code beetween //[1] and //[2] should perform in separate
> thread
> > (and as we can see from the console it really does), but why the main I/O
> > thread are waiting and does not handle other requests?
> >
> > So if my code is correct than it means that Undertow could handle one
> request
> > in time...
> >
> > What I do wrong?
> >
> > Best,
> > Mikhail
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140218/b73db65c/attachment-0001.html 

From lanabe.lanabe at gmail.com  Tue Feb 18 10:03:57 2014
From: lanabe.lanabe at gmail.com (lanabe)
Date: Wed, 19 Feb 2014 00:03:57 +0900
Subject: [undertow-dev] what I do wrong?
In-Reply-To: <CAOKv2Z-UuLq6HwDCQ1O0MfQ4gDJeFyGz84Enoi_anKd9iX4U5Q@mail.gmail.com>
References: <CAOKv2Z-ME8N3sV2bX0M7ENFm52Xd5=eMVk4FXrwz98vf3Aw4vQ@mail.gmail.com>
	<964925076.4821756.1392693753296.JavaMail.zimbra@redhat.com>
	<CAOKv2Z-UuLq6HwDCQ1O0MfQ4gDJeFyGz84Enoi_anKd9iX4U5Q@mail.gmail.com>
Message-ID: <CAKhWDPRMn3QyDjLXL+foTH1izNr00Ng6+XcvCKSuc5EJ0OuAUQ@mail.gmail.com>

Hi, Mikhail.

I got the same log.

[environment]
Undertow: io.undertow:undertow-core:1.0.0.Final
OS: Fedora19(64bit)
JDK: OpenJDK 1.7.0_51
Client: Google Chrome 32.0.1700.107, Firefox 26.0

---
Thread #XNIO-1 I/O-1 is I/O : handle this
Thread #XNIO-1 task-1 Start waiting
Thread #XNIO-1 task-1 Finish waiting

Thread #XNIO-1 I/O-1 is I/O : handle this
Thread #XNIO-1 task-2 Start waiting
Thread #XNIO-1 task-2 Finish waiting

Thread #XNIO-1 I/O-1 is I/O : handle this
Thread #XNIO-1 task-3 Start waiting
Thread #XNIO-1 task-3 Finish waiting
---

but, I got the expected following log by using curl.
---
Thread #XNIO-1 I/O-1 is I/O : handle this
Thread #XNIO-1 task-1 Start waiting
Thread #XNIO-1 I/O-1 is I/O : handle this
Thread #XNIO-1 task-2 Start waiting
Thread #XNIO-1 I/O-2 is I/O : handle this
Thread #XNIO-1 task-3 Start waiting
Thread #XNIO-1 task-1 Finish waiting

Thread #XNIO-1 task-2 Finish waiting

Thread #XNIO-1 task-3 Finish waiting
---

hmm...Does it depends on browser settings?

===
Yoshimasa Tanabe


On Tue, Feb 18, 2014 at 3:10 PM, Mikhail Tyamin
<mikhail.tiamine at gmail.com>wrote:

> Hi,
>
> I am pretty sure, 15 sec. delay is enough to open additional browsers
> windows ;-)
>
> I try to run code with io.undertow:undertow-core:1.0.0.Final on mac with
> OS X 10.9.1   with jdk 1.7.0_51.
>
> So, could anybody reproduce this issue or give me feedback where is my
> error?
>
> Best,
> Mikhail
>
>
> 2014-02-18 5:22 GMT+02:00 Stuart Douglas <sdouglas at redhat.com>:
>
> Are you sure the requests are actually being made simultaneously? That
>> code should definitely work.
>>
>> Stuart
>>
>>
>> ----- Original Message -----
>> > From: "Mikhail Tyamin" <mikhail.tiamine at gmail.com>
>> > To: undertow-dev at lists.jboss.org
>> > Sent: Monday, 17 February, 2014 3:03:41 PM
>> > Subject: [undertow-dev] what I do wrong?
>> >
>> > Hello guys,
>> >
>> > could you help me a little bit with Undertow?
>> >
>> > I follow all instructions in Undertown's poor documentation. So here is
>> the
>> > class :
>> >
>> > public class HelloWorldServer {
>> >
>> > public static void main(String... args) {
>> > Undertow server = Undertow.builder()
>> > .addHttpListener(8080, "localhost")
>> > .setHandler(new HttpHandler() {
>> > @Override
>> > public void handleRequest(final HttpServerExchange exchange) throws
>> Exception
>> > {
>> > if (exchange.isInIoThread()) {
>> > System.out.println("Thread #" + Thread.currentThread().getName() + " is
>> I/O :
>> > handle this");
>> > exchange.dispatch(this);
>> > return;
>> > }
>> >
>> > //[1]
>> > System.out.println("Thread #" + Thread.currentThread().getName() + "
>> Start
>> > waiting");
>> > Thread.sleep(15000);
>> > System.out.println("Thread #" + Thread.currentThread().getName() + "
>> Finish
>> > waiting");
>> >
>> > System.out.println();
>> >
>> > exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
>> > exchange.getResponseSender().send("Hello world from thread " +
>> > Thread.currentThread().getId());
>> > //[2]
>> > }
>> > }).build();
>> >
>> > server.start();
>> > }
>> > }
>> >
>> > When I start it and make three http get request simultaneously I can
>> see this
>> > output in console :
>> >
>> > Thread #XNIO-1 I/O-1 is I/O : handle this
>> > Thread #XNIO-1 task-1 Start waiting
>> > Thread #XNIO-1 task-1 Finish waiting
>> >
>> > Thread #XNIO-1 I/O-1 is I/O : handle this
>> > Thread #XNIO-1 task-2 Start waiting
>> > Thread #XNIO-1 task-2 Finish waiting
>> >
>> > Thread #XNIO-1 I/O-1 is I/O : handle this
>> > Thread #XNIO-1 task-3 Start waiting
>> > Thread #XNIO-1 task-3 Finish waiting
>> >
>> >
>> > I think that code beetween //[1] and //[2] should perform in separate
>> thread
>> > (and as we can see from the console it really does), but why the main
>> I/O
>> > thread are waiting and does not handle other requests?
>> >
>> > So if my code is correct than it means that Undertow could handle one
>> request
>> > in time...
>> >
>> > What I do wrong?
>> >
>> > Best,
>> > Mikhail
>> >
>> > _______________________________________________
>> > undertow-dev mailing list
>> > undertow-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140219/276de324/attachment.html 

From jason.greene at redhat.com  Tue Feb 18 10:29:44 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Tue, 18 Feb 2014 09:29:44 -0600
Subject: [undertow-dev] what I do wrong?
In-Reply-To: <CAKhWDPRMn3QyDjLXL+foTH1izNr00Ng6+XcvCKSuc5EJ0OuAUQ@mail.gmail.com>
References: <CAOKv2Z-ME8N3sV2bX0M7ENFm52Xd5=eMVk4FXrwz98vf3Aw4vQ@mail.gmail.com>
	<964925076.4821756.1392693753296.JavaMail.zimbra@redhat.com>
	<CAOKv2Z-UuLq6HwDCQ1O0MfQ4gDJeFyGz84Enoi_anKd9iX4U5Q@mail.gmail.com>
	<CAKhWDPRMn3QyDjLXL+foTH1izNr00Ng6+XcvCKSuc5EJ0OuAUQ@mail.gmail.com>
Message-ID: <4ACE87E9-CADB-4F8D-9052-7C115CD0CD5E@redhat.com>


On Feb 18, 2014, at 9:03 AM, lanabe <lanabe.lanabe at gmail.com> wrote:
> 
> hmm...Does it depends on browser settings?

Yes, browsers commonly reuse connections, based on their own criteria. You can verify this by installing wireshark and looking at the traffic.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From mikhail.tiamine at gmail.com  Wed Feb 19 12:53:31 2014
From: mikhail.tiamine at gmail.com (Mikhail Tyamin)
Date: Wed, 19 Feb 2014 19:53:31 +0200
Subject: [undertow-dev] what I do wrong?
In-Reply-To: <CAKhWDPSCnCm102v0Z-1wsGz8N2iNbrXq5tzuyAaQ_Hgc3-zhcw@mail.gmail.com>
References: <CAOKv2Z-ME8N3sV2bX0M7ENFm52Xd5=eMVk4FXrwz98vf3Aw4vQ@mail.gmail.com>
	<964925076.4821756.1392693753296.JavaMail.zimbra@redhat.com>
	<CAOKv2Z-UuLq6HwDCQ1O0MfQ4gDJeFyGz84Enoi_anKd9iX4U5Q@mail.gmail.com>
	<CAKhWDPSCnCm102v0Z-1wsGz8N2iNbrXq5tzuyAaQ_Hgc3-zhcw@mail.gmail.com>
Message-ID: <CAOKv2Z8Rb45R_Mv=xPPfDjySzoyXR8HAmOHowYZcuaLFo-tURA@mail.gmail.com>

Hi,

you are right! I tried with Safari and it works as expected.

Maybe somebody from undertow's team could explain why?

Best,
Mikhail

Best,
Mikhail


2014-02-18 16:50 GMT+02:00 lanabe <lanabe.lanabe at gmail.com>:

> Hi, Mikhail.
>
> I got the same log.
>
> [environment]
> Undertow: io.undertow:undertow-core:1.0.0.Final
> OS: Fedora19(64bit)
> JDK: OpenJDK 1.7.0_51
> Client: Google Chrome 32.0.1700.107, Firefox 26.0
>
> ---
> Thread #XNIO-1 I/O-1 is I/O : handle this
> Thread #XNIO-1 task-1 Start waiting
> Thread #XNIO-1 task-1 Finish waiting
>
> Thread #XNIO-1 I/O-1 is I/O : handle this
> Thread #XNIO-1 task-2 Start waiting
> Thread #XNIO-1 task-2 Finish waiting
>
> Thread #XNIO-1 I/O-1 is I/O : handle this
> Thread #XNIO-1 task-3 Start waiting
> Thread #XNIO-1 task-3 Finish waiting
> ---
>
> but, I got the expected following log by using curl.
> ---
> Thread #XNIO-1 I/O-1 is I/O : handle this
> Thread #XNIO-1 task-1 Start waiting
> Thread #XNIO-1 I/O-1 is I/O : handle this
> Thread #XNIO-1 task-2 Start waiting
> Thread #XNIO-1 I/O-2 is I/O : handle this
> Thread #XNIO-1 task-3 Start waiting
> Thread #XNIO-1 task-1 Finish waiting
>
> Thread #XNIO-1 task-2 Finish waiting
>
> Thread #XNIO-1 task-3 Finish waiting
> ---
>
> hmm...Does it depends on browser settings?
>
> Yoshimasa Tanabe
>
>
> On Tue, Feb 18, 2014 at 3:10 PM, Mikhail Tyamin <mikhail.tiamine at gmail.com
> > wrote:
>
>> Hi,
>>
>> I am pretty sure, 15 sec. delay is enough to open additional browsers
>> windows ;-)
>>
>> I try to run code with io.undertow:undertow-core:1.0.0.Final on mac with
>> OS X 10.9.1   with jdk 1.7.0_51.
>>
>> So, could anybody reproduce this issue or give me feedback where is my
>> error?
>>
>> Best,
>> Mikhail
>>
>>
>> 2014-02-18 5:22 GMT+02:00 Stuart Douglas <sdouglas at redhat.com>:
>>
>> Are you sure the requests are actually being made simultaneously? That
>>> code should definitely work.
>>>
>>> Stuart
>>>
>>>
>>> ----- Original Message -----
>>> > From: "Mikhail Tyamin" <mikhail.tiamine at gmail.com>
>>> > To: undertow-dev at lists.jboss.org
>>> > Sent: Monday, 17 February, 2014 3:03:41 PM
>>> > Subject: [undertow-dev] what I do wrong?
>>> >
>>> > Hello guys,
>>> >
>>> > could you help me a little bit with Undertow?
>>> >
>>> > I follow all instructions in Undertown's poor documentation. So here
>>> is the
>>> > class :
>>> >
>>> > public class HelloWorldServer {
>>> >
>>> > public static void main(String... args) {
>>> > Undertow server = Undertow.builder()
>>> > .addHttpListener(8080, "localhost")
>>> > .setHandler(new HttpHandler() {
>>> > @Override
>>> > public void handleRequest(final HttpServerExchange exchange) throws
>>> Exception
>>> > {
>>> > if (exchange.isInIoThread()) {
>>> > System.out.println("Thread #" + Thread.currentThread().getName() + "
>>> is I/O :
>>> > handle this");
>>> > exchange.dispatch(this);
>>> > return;
>>> > }
>>> >
>>> > //[1]
>>> > System.out.println("Thread #" + Thread.currentThread().getName() + "
>>> Start
>>> > waiting");
>>> > Thread.sleep(15000);
>>> > System.out.println("Thread #" + Thread.currentThread().getName() + "
>>> Finish
>>> > waiting");
>>> >
>>> > System.out.println();
>>> >
>>> > exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
>>> > exchange.getResponseSender().send("Hello world from thread " +
>>> > Thread.currentThread().getId());
>>> > //[2]
>>> > }
>>> > }).build();
>>> >
>>> > server.start();
>>> > }
>>> > }
>>> >
>>> > When I start it and make three http get request simultaneously I can
>>> see this
>>> > output in console :
>>> >
>>> > Thread #XNIO-1 I/O-1 is I/O : handle this
>>> > Thread #XNIO-1 task-1 Start waiting
>>> > Thread #XNIO-1 task-1 Finish waiting
>>> >
>>> > Thread #XNIO-1 I/O-1 is I/O : handle this
>>> > Thread #XNIO-1 task-2 Start waiting
>>> > Thread #XNIO-1 task-2 Finish waiting
>>> >
>>> > Thread #XNIO-1 I/O-1 is I/O : handle this
>>> > Thread #XNIO-1 task-3 Start waiting
>>> > Thread #XNIO-1 task-3 Finish waiting
>>> >
>>> >
>>> > I think that code beetween //[1] and //[2] should perform in separate
>>> thread
>>> > (and as we can see from the console it really does), but why the main
>>> I/O
>>> > thread are waiting and does not handle other requests?
>>> >
>>> > So if my code is correct than it means that Undertow could handle one
>>> request
>>> > in time...
>>> >
>>> > What I do wrong?
>>> >
>>> > Best,
>>> > Mikhail
>>> >
>>> > _______________________________________________
>>> > undertow-dev mailing list
>>> > undertow-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140219/66e3e9f8/attachment-0001.html 

From jason.greene at redhat.com  Wed Feb 19 17:47:10 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 19 Feb 2014 16:47:10 -0600
Subject: [undertow-dev] what I do wrong?
In-Reply-To: <CAOKv2Z8Rb45R_Mv=xPPfDjySzoyXR8HAmOHowYZcuaLFo-tURA@mail.gmail.com>
References: <CAOKv2Z-ME8N3sV2bX0M7ENFm52Xd5=eMVk4FXrwz98vf3Aw4vQ@mail.gmail.com>
	<964925076.4821756.1392693753296.JavaMail.zimbra@redhat.com>
	<CAOKv2Z-UuLq6HwDCQ1O0MfQ4gDJeFyGz84Enoi_anKd9iX4U5Q@mail.gmail.com>
	<CAKhWDPSCnCm102v0Z-1wsGz8N2iNbrXq5tzuyAaQ_Hgc3-zhcw@mail.gmail.com>
	<CAOKv2Z8Rb45R_Mv=xPPfDjySzoyXR8HAmOHowYZcuaLFo-tURA@mail.gmail.com>
Message-ID: <8C1705CE-FFCB-4D1F-A488-7C1278FC984F@redhat.com>

It all depends on how the web browser manages connections. Some prefer to reuse aggressively and others don?t. 

The way the undertow architecture works, is that every connection is assigned to an I/O thread for as long as that connection is alive. When there is data available the I/O thread will wake up and process that data, and trigger a call to your handler, and move on to other ready connections. 

On Feb 19, 2014, at 11:53 AM, Mikhail Tyamin <mikhail.tiamine at gmail.com> wrote:

> Hi,
> 
> you are right! I tried with Safari and it works as expected.
> 
> Maybe somebody from undertow's team could explain why?
> 
> Best,
> Mikhail
> 
> Best,
> Mikhail
> 
> 
> 2014-02-18 16:50 GMT+02:00 lanabe <lanabe.lanabe at gmail.com>:
> Hi, Mikhail.
> 
> I got the same log.
> 
> [environment]
> Undertow: io.undertow:undertow-core:1.0.0.Final
> OS: Fedora19(64bit)
> JDK: OpenJDK 1.7.0_51
> Client: Google Chrome 32.0.1700.107, Firefox 26.0
> 
> ---
> Thread #XNIO-1 I/O-1 is I/O : handle this
> Thread #XNIO-1 task-1 Start waiting
> Thread #XNIO-1 task-1 Finish waiting
> 
> Thread #XNIO-1 I/O-1 is I/O : handle this
> Thread #XNIO-1 task-2 Start waiting
> Thread #XNIO-1 task-2 Finish waiting
> 
> Thread #XNIO-1 I/O-1 is I/O : handle this
> Thread #XNIO-1 task-3 Start waiting
> Thread #XNIO-1 task-3 Finish waiting
> ---
> 
> but, I got the expected following log by using curl.
> ---
> Thread #XNIO-1 I/O-1 is I/O : handle this
> Thread #XNIO-1 task-1 Start waiting
> Thread #XNIO-1 I/O-1 is I/O : handle this
> Thread #XNIO-1 task-2 Start waiting
> Thread #XNIO-1 I/O-2 is I/O : handle this
> Thread #XNIO-1 task-3 Start waiting
> Thread #XNIO-1 task-1 Finish waiting
> 
> Thread #XNIO-1 task-2 Finish waiting
> 
> Thread #XNIO-1 task-3 Finish waiting
> ---
> 
> hmm...Does it depends on browser settings?
> 
> Yoshimasa Tanabe
> 
> 
> On Tue, Feb 18, 2014 at 3:10 PM, Mikhail Tyamin <mikhail.tiamine at gmail.com> wrote:
> Hi,
> 
> I am pretty sure, 15 sec. delay is enough to open additional browsers windows ;-)
> 
> I try to run code with io.undertow:undertow-core:1.0.0.Final on mac with OS X 10.9.1   with jdk 1.7.0_51.
> 
> So, could anybody reproduce this issue or give me feedback where is my error?
> 
> Best,
> Mikhail
> 
> 
> 2014-02-18 5:22 GMT+02:00 Stuart Douglas <sdouglas at redhat.com>:
> 
> Are you sure the requests are actually being made simultaneously? That code should definitely work.
> 
> Stuart
> 
> 
> ----- Original Message -----
> > From: "Mikhail Tyamin" <mikhail.tiamine at gmail.com>
> > To: undertow-dev at lists.jboss.org
> > Sent: Monday, 17 February, 2014 3:03:41 PM
> > Subject: [undertow-dev] what I do wrong?
> >
> > Hello guys,
> >
> > could you help me a little bit with Undertow?
> >
> > I follow all instructions in Undertown's poor documentation. So here is the
> > class :
> >
> > public class HelloWorldServer {
> >
> > public static void main(String... args) {
> > Undertow server = Undertow.builder()
> > .addHttpListener(8080, "localhost")
> > .setHandler(new HttpHandler() {
> > @Override
> > public void handleRequest(final HttpServerExchange exchange) throws Exception
> > {
> > if (exchange.isInIoThread()) {
> > System.out.println("Thread #" + Thread.currentThread().getName() + " is I/O :
> > handle this");
> > exchange.dispatch(this);
> > return;
> > }
> >
> > //[1]
> > System.out.println("Thread #" + Thread.currentThread().getName() + " Start
> > waiting");
> > Thread.sleep(15000);
> > System.out.println("Thread #" + Thread.currentThread().getName() + " Finish
> > waiting");
> >
> > System.out.println();
> >
> > exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
> > exchange.getResponseSender().send("Hello world from thread " +
> > Thread.currentThread().getId());
> > //[2]
> > }
> > }).build();
> >
> > server.start();
> > }
> > }
> >
> > When I start it and make three http get request simultaneously I can see this
> > output in console :
> >
> > Thread #XNIO-1 I/O-1 is I/O : handle this
> > Thread #XNIO-1 task-1 Start waiting
> > Thread #XNIO-1 task-1 Finish waiting
> >
> > Thread #XNIO-1 I/O-1 is I/O : handle this
> > Thread #XNIO-1 task-2 Start waiting
> > Thread #XNIO-1 task-2 Finish waiting
> >
> > Thread #XNIO-1 I/O-1 is I/O : handle this
> > Thread #XNIO-1 task-3 Start waiting
> > Thread #XNIO-1 task-3 Finish waiting
> >
> >
> > I think that code beetween //[1] and //[2] should perform in separate thread
> > (and as we can see from the console it really does), but why the main I/O
> > thread are waiting and does not handle other requests?
> >
> > So if my code is correct than it means that Undertow could handle one request
> > in time...
> >
> > What I do wrong?
> >
> > Best,
> > Mikhail
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> 
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From lanabe.lanabe at gmail.com  Thu Feb 20 22:31:17 2014
From: lanabe.lanabe at gmail.com (lanabe)
Date: Fri, 21 Feb 2014 12:31:17 +0900
Subject: [undertow-dev] what I do wrong?
In-Reply-To: <8C1705CE-FFCB-4D1F-A488-7C1278FC984F@redhat.com>
References: <CAOKv2Z-ME8N3sV2bX0M7ENFm52Xd5=eMVk4FXrwz98vf3Aw4vQ@mail.gmail.com>
	<964925076.4821756.1392693753296.JavaMail.zimbra@redhat.com>
	<CAOKv2Z-UuLq6HwDCQ1O0MfQ4gDJeFyGz84Enoi_anKd9iX4U5Q@mail.gmail.com>
	<CAKhWDPSCnCm102v0Z-1wsGz8N2iNbrXq5tzuyAaQ_Hgc3-zhcw@mail.gmail.com>
	<CAOKv2Z8Rb45R_Mv=xPPfDjySzoyXR8HAmOHowYZcuaLFo-tURA@mail.gmail.com>
	<8C1705CE-FFCB-4D1F-A488-7C1278FC984F@redhat.com>
Message-ID: <CAKhWDPTnRCvjSdJ3O-MEpCLA-WUcrTs1ZVmSGQFs7LppoYVscA@mail.gmail.com>

Hi, Jason.

Thank you for your explanation. I got it.

[FYI]
>>> I tried with Safari and it works as expected.

I checked IE8(sorry for legacy...) also don't reuse connection.

===
Yoshimasa Tanabe


On Thu, Feb 20, 2014 at 7:47 AM, Jason Greene <jason.greene at redhat.com>wrote:

> It all depends on how the web browser manages connections. Some prefer to
> reuse aggressively and others don't.
>
> The way the undertow architecture works, is that every connection is
> assigned to an I/O thread for as long as that connection is alive. When
> there is data available the I/O thread will wake up and process that data,
> and trigger a call to your handler, and move on to other ready connections.
>
> On Feb 19, 2014, at 11:53 AM, Mikhail Tyamin <mikhail.tiamine at gmail.com>
> wrote:
>
> > Hi,
> >
> > you are right! I tried with Safari and it works as expected.
> >
> > Maybe somebody from undertow's team could explain why?
> >
> > Best,
> > Mikhail
> >
> > Best,
> > Mikhail
> >
> >
> > 2014-02-18 16:50 GMT+02:00 lanabe <lanabe.lanabe at gmail.com>:
> > Hi, Mikhail.
> >
> > I got the same log.
> >
> > [environment]
> > Undertow: io.undertow:undertow-core:1.0.0.Final
> > OS: Fedora19(64bit)
> > JDK: OpenJDK 1.7.0_51
> > Client: Google Chrome 32.0.1700.107, Firefox 26.0
> >
> > ---
> > Thread #XNIO-1 I/O-1 is I/O : handle this
> > Thread #XNIO-1 task-1 Start waiting
> > Thread #XNIO-1 task-1 Finish waiting
> >
> > Thread #XNIO-1 I/O-1 is I/O : handle this
> > Thread #XNIO-1 task-2 Start waiting
> > Thread #XNIO-1 task-2 Finish waiting
> >
> > Thread #XNIO-1 I/O-1 is I/O : handle this
> > Thread #XNIO-1 task-3 Start waiting
> > Thread #XNIO-1 task-3 Finish waiting
> > ---
> >
> > but, I got the expected following log by using curl.
> > ---
> > Thread #XNIO-1 I/O-1 is I/O : handle this
> > Thread #XNIO-1 task-1 Start waiting
> > Thread #XNIO-1 I/O-1 is I/O : handle this
> > Thread #XNIO-1 task-2 Start waiting
> > Thread #XNIO-1 I/O-2 is I/O : handle this
> > Thread #XNIO-1 task-3 Start waiting
> > Thread #XNIO-1 task-1 Finish waiting
> >
> > Thread #XNIO-1 task-2 Finish waiting
> >
> > Thread #XNIO-1 task-3 Finish waiting
> > ---
> >
> > hmm...Does it depends on browser settings?
> >
> > Yoshimasa Tanabe
> >
> >
> > On Tue, Feb 18, 2014 at 3:10 PM, Mikhail Tyamin <
> mikhail.tiamine at gmail.com> wrote:
> > Hi,
> >
> > I am pretty sure, 15 sec. delay is enough to open additional browsers
> windows ;-)
> >
> > I try to run code with io.undertow:undertow-core:1.0.0.Final on mac with
> OS X 10.9.1   with jdk 1.7.0_51.
> >
> > So, could anybody reproduce this issue or give me feedback where is my
> error?
> >
> > Best,
> > Mikhail
> >
> >
> > 2014-02-18 5:22 GMT+02:00 Stuart Douglas <sdouglas at redhat.com>:
> >
> > Are you sure the requests are actually being made simultaneously? That
> code should definitely work.
> >
> > Stuart
> >
> >
> > ----- Original Message -----
> > > From: "Mikhail Tyamin" <mikhail.tiamine at gmail.com>
> > > To: undertow-dev at lists.jboss.org
> > > Sent: Monday, 17 February, 2014 3:03:41 PM
> > > Subject: [undertow-dev] what I do wrong?
> > >
> > > Hello guys,
> > >
> > > could you help me a little bit with Undertow?
> > >
> > > I follow all instructions in Undertown's poor documentation. So here
> is the
> > > class :
> > >
> > > public class HelloWorldServer {
> > >
> > > public static void main(String... args) {
> > > Undertow server = Undertow.builder()
> > > .addHttpListener(8080, "localhost")
> > > .setHandler(new HttpHandler() {
> > > @Override
> > > public void handleRequest(final HttpServerExchange exchange) throws
> Exception
> > > {
> > > if (exchange.isInIoThread()) {
> > > System.out.println("Thread #" + Thread.currentThread().getName() + "
> is I/O :
> > > handle this");
> > > exchange.dispatch(this);
> > > return;
> > > }
> > >
> > > //[1]
> > > System.out.println("Thread #" + Thread.currentThread().getName() + "
> Start
> > > waiting");
> > > Thread.sleep(15000);
> > > System.out.println("Thread #" + Thread.currentThread().getName() + "
> Finish
> > > waiting");
> > >
> > > System.out.println();
> > >
> > > exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
> > > exchange.getResponseSender().send("Hello world from thread " +
> > > Thread.currentThread().getId());
> > > //[2]
> > > }
> > > }).build();
> > >
> > > server.start();
> > > }
> > > }
> > >
> > > When I start it and make three http get request simultaneously I can
> see this
> > > output in console :
> > >
> > > Thread #XNIO-1 I/O-1 is I/O : handle this
> > > Thread #XNIO-1 task-1 Start waiting
> > > Thread #XNIO-1 task-1 Finish waiting
> > >
> > > Thread #XNIO-1 I/O-1 is I/O : handle this
> > > Thread #XNIO-1 task-2 Start waiting
> > > Thread #XNIO-1 task-2 Finish waiting
> > >
> > > Thread #XNIO-1 I/O-1 is I/O : handle this
> > > Thread #XNIO-1 task-3 Start waiting
> > > Thread #XNIO-1 task-3 Finish waiting
> > >
> > >
> > > I think that code beetween //[1] and //[2] should perform in separate
> thread
> > > (and as we can see from the console it really does), but why the main
> I/O
> > > thread are waiting and does not handle other requests?
> > >
> > > So if my code is correct than it means that Undertow could handle one
> request
> > > in time...
> > >
> > > What I do wrong?
> > >
> > > Best,
> > > Mikhail
> > >
> > > _______________________________________________
> > > undertow-dev mailing list
> > > undertow-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140221/8e65f859/attachment.html 

From bburke at redhat.com  Sat Feb 22 07:01:48 2014
From: bburke at redhat.com (Bill Burke)
Date: Sat, 22 Feb 2014 07:01:48 -0500
Subject: [undertow-dev] principal/role propagation
Message-ID: <530891AC.5030607@redhat.com>

Where does an Undertow Account get propagated to the Wildfly security 
layer so principal/roles can be propagated to layers like EJB?
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From ccristia at adobe.com  Sat Feb 22 07:13:29 2014
From: ccristia at adobe.com (Cristian Constantin)
Date: Sat, 22 Feb 2014 12:13:29 +0000
Subject: [undertow-dev] Reverse proxy roadmap
Message-ID: <CF2E6103.981B%ccristia@adobe.com>

Hi,

I am interested in using Undertow as a reverse proxy solution and I would like to know what are the future development plans in this area: what features could we expect? is there a public roadmap somewhere? do you accept contributions?

Regards,
Cristian Constantin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140222/6e28ea78/attachment-0001.html 

From sdouglas at redhat.com  Sun Feb 23 20:36:52 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Sun, 23 Feb 2014 20:36:52 -0500 (EST)
Subject: [undertow-dev] principal/role propagation
In-Reply-To: <530891AC.5030607@redhat.com>
References: <530891AC.5030607@redhat.com>
Message-ID: <2014617187.7802509.1393205812490.JavaMail.zimbra@redhat.com>

This all happens in the Wildfly code base, using Undertow handlers and ThreadSetupActions.

org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction - This creates the picketbox security context and sets up the association. 
org.wildfly.extension.undertow.security.JAASIdentityManagerImpl - Populates the picketbox security context when the undertow Account is created. This is kinda yuck, but there is no other way to do this as far as I can see.

org.wildfly.extension.undertow.security.SecurityContextAssociationHandler - Handles RunAs 

Stuart

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: undertow-dev at lists.jboss.org
> Sent: Saturday, 22 February, 2014 5:31:48 PM
> Subject: [undertow-dev] principal/role propagation
> 
> Where does an Undertow Account get propagated to the Wildfly security
> layer so principal/roles can be propagated to layers like EJB?
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

From sdouglas at redhat.com  Sun Feb 23 20:50:17 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Sun, 23 Feb 2014 20:50:17 -0500 (EST)
Subject: [undertow-dev] Reverse proxy roadmap
In-Reply-To: <CF2E6103.981B%ccristia@adobe.com>
References: <CF2E6103.981B%ccristia@adobe.com>
Message-ID: <660599706.7805868.1393206617228.JavaMail.zimbra@redhat.com>

Hi Cristian,

The main thing we are working on at the moment is support for mod_proxy based dynamic load balancing. We most certainly do accept contributions, but if you have any changes you would like it is generally best to discuss it here first (unless it is an obvious bug or something simple). 

Stuart

----- Original Message -----
> From: "Cristian Constantin" <ccristia at adobe.com>
> To: undertow-dev at lists.jboss.org
> Sent: Saturday, 22 February, 2014 5:43:29 PM
> Subject: [undertow-dev] Reverse proxy roadmap
> 
> Hi,
> 
> I am interested in using Undertow as a reverse proxy solution and I would
> like to know what are the future development plans in this area: what
> features could we expect? is there a public roadmap somewhere? do you accept
> contributions?
> 
> Regards,
> Cristian Constantin
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From bburke at redhat.com  Fri Feb 28 19:39:25 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 28 Feb 2014 19:39:25 -0500
Subject: [undertow-dev] CachedAuthenticatedSessionMechanism should return
	NOT_ATTEMPTED?
Message-ID: <53112C3D.9060706@redhat.com>

If IdentityManager.verify(Account) returns null, shouldn't 
CachedAuthenticatedSessionMechanism return NOT_ATTEMPTED instead of 
aborting and returning 403/NOT_AUTHENTICATED?  I was expecting that 
returning null would start the auth process again.




-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com