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.
I'm noticing that I can't pull an attachment back off the exchange using
AttachmentKey.create(Class), presumably because AttachmentKey (or rather
SimpleAttachmentKey) doesn't override equals to compare based on the
wrapped Class object, so it's using object identity, which obviously
Is this by design? Do I need to hold onto the key I used to add the
attachment in the first place? This seems a bit counter-intuitive, as it
means pushing keys around between handlers, when simply implementing equals
on the key would avoid that. Am I supposed to provide my own key
implementation (i.e basically rewrite SimpleAttachment key - I can't
believe that this is the answer)?
Or am I just missing something obvious?
url. Traditionally, web containers (Tomcat and Jetty) have used http
session to remember the redirect url.
If an user has turned off cookies, then it may not work.
I am wondering if a flag can be set in ChallengeResult such that
undertow does not try to set the response code on the httpserverexchange
before sending the challenge?
The reason is that an authentication mechanism may have already utilized
the httpservletresponse object to set a response code such as:
Now since undertow tries to set a response code on the
httpServerExchange, there is an error.
I am trying to understand the reasoning behind the new factory added
for authentication mechanisms
Why not just allow the direct install of authentication mechanisms like
we did before in the DeploymentInfo?
I am unsure we need another level of indirection with this factory which
also has access to the FormDataParser. Basically, the specifics of FORM
authentication have sneaked into this factory. Many of the
authentication mechanisms do not even involve forms.
looking at the FormAuthenticationMechanism code, I cannot figure out
whether the original request gets cached (saved) before redirecting to
the form login page. After authentication, it needs to be restored back.
This is the only way in which the original post data to a secured URL
can be saved after the form authentication work flow.
can the authentication mechanism have a lifecycle based on the
I need access to the ServletContext to look for deployment descriptors
using the servletContext.getResourceAsStream() call.
I am thinking something along the lines of:
This will give an opportunity for the authentication mechanism to
initialize and finalize any resources.
Now Undertow AccessLogHandler is not supported Response time(%D/%T), right?
I simply implemented it, but I'm not sure..
My code is
1) Add startTime:long field in HttpServerExchange
2) Initialize startTime and assign System.currentTimeMillis to it in
3) Create ResponseTimeAttribute and its readAttribute return
(System.currentTimeMillis - exchage.getStartTime)
Is it too simple?
I checked handler chain stack trace on WildFly Beta1.
<Some Handlers> -> AccessLogHandler -> PathHandler -> ResourceHandler
If PathHandler and ResourceHandler(or another process) take a long time, my
idea doesn't work.