Can we please have a notification scheme enabled for Undertow Jira?
by Darran Lofthouse
Can we please have a notification scheme enabling for the Undertow Jira
project so that we can receive e-mail notifications.
I would suggest just use the same one as is used for Remoting JMX, it
should be sufficient to have the notifications go to the general mailing
list and interested individuals.
Regards,
Darran Lofthouse.
11 years, 7 months
Sharing session attributes in NonBlocking Handlers and Traditional Servlets
by Lightspoke Discussion
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
12 years
Reverse proxy roadmap
by Cristian Constantin
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
12 years
Re: [undertow-dev] what I do wrong?
by Mikhail Tyamin
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(a)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(a)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(a)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(a)gmail.com>
>>> > To: undertow-dev(a)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(a)lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>
>
12 years
what I do wrong?
by Mikhail Tyamin
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
12 years
Security constraints and population of ServletSecurityInfo
by Paul K Moore
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 :)
12 years
Class loader stacktraces on undeploy/deploy
by Wolfgang Knauf
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
12 years
