From jbartece at redhat.com  Tue Jul  1 05:18:22 2014
From: jbartece at redhat.com (Jakub Bartecek)
Date: Tue, 01 Jul 2014 11:18:22 +0200
Subject: [undertow-dev] JDK6 Support
In-Reply-To: <5C9966FF-77DD-4327-8F18-8FF1FFE89172@redhat.com>
References: <53B14AAF.9020209@redhat.com>	<CAMquZP5htLkZriy8+uE0d0c2jPY+mLJhuw6AgGJNiGW0m9z_2A@mail.gmail.com>	<53B15312.8010505@redhat.com>
	<5C9966FF-77DD-4327-8F18-8FF1FFE89172@redhat.com>
Message-ID: <53B27CDE.2040708@redhat.com>

The support of servlet 3.1 on JDK 6 is really interesting for Jenkins 
community, but Jetty does not provide it.
And current Jetty is running on JDK7, so Jenkins has to use old version 
of Jetty.

Jakub

On 06/30/2014 05:59 PM, Jason Greene wrote:
> Does the Jetty support only use the Core API (and not servlet)?
>
> Part of the reason we dropped JDK6 support is because supporting it with servlet 3.1 would have required more work that was hard to justify. 3.1 is tied to JDK7 APIs, so we would have create a special hacked version for it to work.
>
>
> On Jun 30, 2014, at 7:07 AM, Vaclav Tunka <vtunka at redhat.com> wrote:
>
>> Hi Tomaz,
>>
>> I think Jenkins will stay with JDK6 for some time. Jenkins is currently
>> on 1.570 release and I think the compatibility could be broken maybe in
>> Jenkins 2.x, which could take quite a while. Jenkins community is taking
>> stability & contract on runtimes quite seriously.
>>
>> Undertow 1.0.x could be maybe used as tech preview in Jenkins alongside
>> Jetty, but then it misses the point in my opinion.
>>
>> Jetty has advantage compared to Undertow for Jenkins users, that it
>> supports SPDY, which is yet to be supported in Undertow.
>>
>> Anyway the time to react was quite small for this decision in my opinion
>> (~4 days including TZ differences).
>>
>> Cheers,
>> Vaclav
>>
>> On 06/30/2014 01:50 PM, Toma? Cerar wrote:
>>> I think you missed that train for a bit...
>>>
>>> In any case, 1.0.x branch is and will stay on JDK6.
>>> Only master is on JDK7 now.
>>> I think that in near future also Jenkins will move to require JDK7 at
>>> that time you will be able to upgrade to Undertow 1.1+.
>>>
>>> --
>>> tomaz
>>>
>>>
>>> On Mon, Jun 30, 2014 at 1:31 PM, Jakub Bartecek <jbartece at redhat.com
>>> <mailto:jbartece at redhat.com>> wrote:
>>>
>>>     I am responding to discussion about JDK6 support. I prepared integration of Undertow into Jenkins CI and the community just
>>>     considering it, but for the community is important compatibility with JDK6. Is it possible to keep Undertow on JDK6?
>>>
>>>     Jakub Bartecek
>>>
>>>> The recent report from JRebel Labs that surveyed developers said that
>>>> majority of the developers are
>>>> already on JDK7 with a small footprint for JDK6.
>>>>
>>>>
>>>>> On 06/11/2014 10:24 AM, Stuart Douglas wrote:
>>>>> /  Given that no one replied we have now moved to JDK7.
>>>     />>/
>>>     />/> Stuart
>>>     />>/
>>>     />>/> Jason Greene wrote:
>>>     />>>/  Is there anyone using undertow on JDK6, and cares that we continue to support it? We are considering dropping it.
>>>     />>>/
>>>     />>>/  --
>>>     />>>/  Jason T. Greene
>>>     />>>/  WildFly Lead / JBoss EAP Platform Architect
>>>     />>>/  JBoss, a division of Red Hat
>>>     />>>/
>>>     />>>
>>>
>>>
>>>     _______________________________________________
>>>     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
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>> -- 
>> Vaclav Tunka
>> Enterprise Application Platforms
>> JBoss by Red Hat
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From tomaz.cerar at gmail.com  Tue Jul  1 05:22:06 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 1 Jul 2014 11:22:06 +0200
Subject: [undertow-dev] JDK6 Support
In-Reply-To: <53B27CDE.2040708@redhat.com>
References: <53B14AAF.9020209@redhat.com>
	<CAMquZP5htLkZriy8+uE0d0c2jPY+mLJhuw6AgGJNiGW0m9z_2A@mail.gmail.com>
	<53B15312.8010505@redhat.com>
	<5C9966FF-77DD-4327-8F18-8FF1FFE89172@redhat.com>
	<53B27CDE.2040708@redhat.com>
Message-ID: <CAMquZP6KTJv6Y2MPAARGVOVJ1thGAgEUkgqavzgOpFzGgPpyxw@mail.gmail.com>

On Tue, Jul 1, 2014 at 11:18 AM, Jakub Bartecek <jbartece at redhat.com> wrote:

> And current Jetty is running on JDK7, so Jenkins has to use old version
> of Jetty.
>


So it is has same problem as Undertow at this point.
JDK6 is extra old and EOL for more then year now...
Heck, JDK7 is planned to be EOL in March 2015
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140701/d0c1ca1c/attachment.html 

From arjan.tijms at gmail.com  Tue Jul  1 05:57:15 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Tue, 1 Jul 2014 11:57:15 +0200
Subject: [undertow-dev] JDK6 Support
In-Reply-To: <CAMquZP6KTJv6Y2MPAARGVOVJ1thGAgEUkgqavzgOpFzGgPpyxw@mail.gmail.com>
References: <53B14AAF.9020209@redhat.com>
	<CAMquZP5htLkZriy8+uE0d0c2jPY+mLJhuw6AgGJNiGW0m9z_2A@mail.gmail.com>
	<53B15312.8010505@redhat.com>
	<5C9966FF-77DD-4327-8F18-8FF1FFE89172@redhat.com>
	<53B27CDE.2040708@redhat.com>
	<CAMquZP6KTJv6Y2MPAARGVOVJ1thGAgEUkgqavzgOpFzGgPpyxw@mail.gmail.com>
Message-ID: <CAE=-AhDv_MF92pZmqN=jdA55xc0q-q4kEjYcLUDzKfUmxEjYxA@mail.gmail.com>

On Tue, Jul 1, 2014 at 11:22 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:

> So it is has same problem as Undertow at this point.
> JDK6 is extra old and EOL for more then year now...
> Heck, JDK7 is planned to be EOL in March 2015
>

Plus, if you stay on JDK6, the step to JDK8 will be even bigger and
probably further away. And I guess a lot of people really want to upgrade
to JDK8 and take advantage of its features.

Regards,
Arjan



>
> _______________________________________________
> 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/20140701/9de32d8a/attachment.html 

From bill at dartalley.com  Wed Jul  2 10:02:09 2014
From: bill at dartalley.com (Bill O'Neil)
Date: Wed, 2 Jul 2014 10:02:09 -0400
Subject: [undertow-dev] Undertow extensions library?
Message-ID: <CANd+gFyH7mx38dt264UdaurS+aAOeXPQEim-i_wT3WKR_t4iCg@mail.gmail.com>

Is there any plan to open up an undertow-ext library where the community
can make small modules that hook into 3rd party dependencies?  For example,
an HttpHandler that uses Jackson/Gson to serialize to json and set
appropriate headers, or an HTML templating framework for rendering HTML.

Would you prefer these to be hosted by 3rd parties instead?

Thanks,
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140702/cb34d952/attachment.html 

From sdouglas at redhat.com  Wed Jul  2 10:44:25 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 02 Jul 2014 10:44:25 -0400
Subject: [undertow-dev] Undertow extensions library?
In-Reply-To: <CANd+gFyH7mx38dt264UdaurS+aAOeXPQEim-i_wT3WKR_t4iCg@mail.gmail.com>
References: <CANd+gFyH7mx38dt264UdaurS+aAOeXPQEim-i_wT3WKR_t4iCg@mail.gmail.com>
Message-ID: <53B41AC9.40102@redhat.com>

This is the first time the question has come up, but I would definitely 
be open to it.

Stuart

Bill O'Neil wrote:
> Is there any plan to open up an undertow-ext library where the community
> can make small modules that hook into 3rd party dependencies?  For
> example, an HttpHandler that uses Jackson/Gson to serialize to json and
> set appropriate headers, or an HTML templating framework for rendering HTML.
>
> Would you prefer these to be hosted by 3rd parties instead?
>
> Thanks,
> Bill
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From jason.greene at redhat.com  Wed Jul  2 10:44:51 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 2 Jul 2014 09:44:51 -0500
Subject: [undertow-dev] Undertow extensions library?
In-Reply-To: <CANd+gFyH7mx38dt264UdaurS+aAOeXPQEim-i_wT3WKR_t4iCg@mail.gmail.com>
References: <CANd+gFyH7mx38dt264UdaurS+aAOeXPQEim-i_wT3WKR_t4iCg@mail.gmail.com>
Message-ID: <4129B9B4-BDA1-47C6-9358-3AE3162EFAD3@redhat.com>

On Jul 2, 2014, at 9:02 AM, Bill O'Neil <bill at dartalley.com> wrote:

> Is there any plan to open up an undertow-ext library where the community can make small modules that hook into 3rd party dependencies?  For example, an HttpHandler that uses Jackson/Gson to serialize to json and set appropriate headers, or an HTML templating framework for rendering HTML.
> 
> Would you prefer these to be hosted by 3rd parties instead?

I think this is a great idea. Are you interested in being a maintainer of such a thing?

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



From bill at dartalley.com  Thu Jul  3 09:28:37 2014
From: bill at dartalley.com (Bill O'Neil)
Date: Thu, 3 Jul 2014 09:28:37 -0400
Subject: [undertow-dev] Undertow extensions library?
In-Reply-To: <4129B9B4-BDA1-47C6-9358-3AE3162EFAD3@redhat.com>
References: <CANd+gFyH7mx38dt264UdaurS+aAOeXPQEim-i_wT3WKR_t4iCg@mail.gmail.com>
	<4129B9B4-BDA1-47C6-9358-3AE3162EFAD3@redhat.com>
Message-ID: <CANd+gFzZ6GsEU0tsiLiU8jeC6_F5ggB+OxriScaapKpMYugKFw@mail.gmail.com>

I have mostly just been getting familiar with undertow for side projects.
 I would be happy to share anything I come up with though to get some
feedback.


On Wed, Jul 2, 2014 at 10:44 AM, Jason Greene <jason.greene at redhat.com>
wrote:

> On Jul 2, 2014, at 9:02 AM, Bill O'Neil <bill at dartalley.com> wrote:
>
> > Is there any plan to open up an undertow-ext library where the community
> can make small modules that hook into 3rd party dependencies?  For example,
> an HttpHandler that uses Jackson/Gson to serialize to json and set
> appropriate headers, or an HTML templating framework for rendering HTML.
> >
> > Would you prefer these to be hosted by 3rd parties instead?
>
> I think this is a great idea. Are you interested in being a maintainer of
> such a thing?
>
> --
> 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/20140703/97571e6f/attachment.html 

From goldsmith.tee at gmail.com  Tue Jul  8 12:40:36 2014
From: goldsmith.tee at gmail.com (Tom Goldsmith)
Date: Tue, 8 Jul 2014 12:40:36 -0400
Subject: [undertow-dev] GZIP Compression
Message-ID: <CAGgVgf6PtXY7W=ASfbADsLtCtGu64DmkM1WH2vzc__dk4OPbaA@mail.gmail.com>

Hi there,

I am wondering what the most idiomatic way to enable GZIP compression is in
the current version of immutant. We could add a config to the WAR file we
are deploying but I'm curious if there is another way of enabling GZIP
either through code or just with the use of a header.

Thanks!
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140708/299f790f/attachment.html 

From tomaz.cerar at gmail.com  Tue Jul  8 13:01:07 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 8 Jul 2014 19:01:07 +0200
Subject: [undertow-dev] GZIP Compression
In-Reply-To: <CAGgVgf6PtXY7W=ASfbADsLtCtGu64DmkM1WH2vzc__dk4OPbaA@mail.gmail.com>
References: <CAGgVgf6PtXY7W=ASfbADsLtCtGu64DmkM1WH2vzc__dk4OPbaA@mail.gmail.com>
Message-ID: <CAMquZP4=fF93SFL_jjdvhEh0WhBLOY3GjXL94NLuEkwH+vOTEg@mail.gmail.com>

Not sure for immutatnt.
but with vanillla wildfly, you would configure that in undertow subsystem.

With vanilla undertow that would mean to add GZIP handler to the chain.

So this would be question more for Immutant guys than here.

--
tomaz


On Tue, Jul 8, 2014 at 6:40 PM, Tom Goldsmith <goldsmith.tee at gmail.com>
wrote:

> Hi there,
>
> I am wondering what the most idiomatic way to enable GZIP compression is
> in the current version of immutant. We could add a config to the WAR file
> we are deploying but I'm curious if there is another way of enabling GZIP
> either through code or just with the use of a header.
>
> Thanks!
> Tom
>
> _______________________________________________
> 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/20140708/bedb2eb9/attachment.html 

From bill at dartalley.com  Sat Jul 19 13:46:11 2014
From: bill at dartalley.com (Bill O'Neil)
Date: Sat, 19 Jul 2014 13:46:11 -0400
Subject: [undertow-dev] Undertow extensions library?
In-Reply-To: <CANd+gFzZ6GsEU0tsiLiU8jeC6_F5ggB+OxriScaapKpMYugKFw@mail.gmail.com>
References: <CANd+gFyH7mx38dt264UdaurS+aAOeXPQEim-i_wT3WKR_t4iCg@mail.gmail.com>
	<4129B9B4-BDA1-47C6-9358-3AE3162EFAD3@redhat.com>
	<CANd+gFzZ6GsEU0tsiLiU8jeC6_F5ggB+OxriScaapKpMYugKFw@mail.gmail.com>
Message-ID: <CANd+gFzuPpy9Oqc0jYxK8x4CjgaBMhyx0p-hvUPWH-a_nWxD-w@mail.gmail.com>

I had a few ideas I put together and would appreciate some feedback.  A lot
of it revolves around Java 8 but I kept all of the extensions themselves at
Java 7.  The main goal of Java 8 was to make constructing HttpHandlers
easier when you delegate to other handlers.

Example:

Handlers.routing()
            .add(Methods.GET, "/messages", HandlerBuilder
                .create(CustomHandlers.json(Messages::getMessages))
                .wrap(CustomHandlers::timing, "getMessages")
                .wrap(BlockingHandler::new)

             .build())

Here is my branch https://github.com/billoneil/undertow/tree/feature/ext

Here is the entry point to an example that puts it all together.
https://github.com/billoneil/undertow/blob/feature/ext/ext/examples/src/main/java/io/undertow/ext/examples/rest/RestServer.java

Please excuse the boring example I couldn't think of anything interesting.

If you run it locally


curl -X POST localhost:8080/messages/optional -d '{"title": "Optional",
"message": "Using optional"}'
{"success":true}

curl -X POST localhost:8080/messages/lambda -d '{"title": "Lambda",
"message": "Using Lambda"}'
{"success":true}

curl -X POST localhost:8080/messages -d '{"title": "Method References",
"message": "Using method references"}'
{"success":true}

curl -X GET localhost:8080/messages
[

   -
   {
      - title: "Optional",
      - message: "Using optional"
      },
   -
   {
      - title: "Lambda",
      - message: "Using Lambda"
      },
   -
   {
      - title: "Method References",
      - message: "Using method references"
      }

]

curl -X GET localhost:8080/info/metrics
{

   - version: "3.0.0",
   - gauges: { },
   - counters: { },
   - histograms: { },
   - meters:
   {
      - response.status.code.200:
      {
         - count: 8,
         - m15_rate: 21.787938213503697,
         - m1_rate: 6.5304307794735275,
         - m5_rate: 18.017228623496,
         - mean_rate: 4.457584495510739,
         - units: "events/minute"
         }
      },
   - timers:
   {
      - createMessageLambda:
      {
         - count: 1,
         - max: 1.169,
         - mean: 1.169,
         - min: 1.169,
         - p50: 1.169,
         - p75: 1.169,
         - p95: 1.169,
         - p98: 1.169,
         - p99: 1.169,
         - p999: 1.169,
         - stddev: 0,
         - m15_rate: 0.059490549916151686,
         - m1_rate: 0.1812199126454006,
         - m5_rate: 0.14211865026090975,
         - mean_rate: 0.5343847126926461,
         - duration_units: "milliseconds",
         - rate_units: "calls/minute"
         },
      - createMessageMethodReferences:
      {
         - count: 1,
         - max: 0.648,
         - mean: 0.648,
         - min: 0.648,
         - p50: 0.648,
         - p75: 0.648,
         - p95: 0.648,
         - p98: 0.648,
         - p99: 0.648,
         - p999: 0.648,
         - stddev: 0,
         - m15_rate: 0.05982197273776584,
         - m1_rate: 0.19696865690816925,
         - m5_rate: 0.14450714325124409,
         - mean_rate: 0.5343791108783038,
         - duration_units: "milliseconds",
         - rate_units: "calls/minute"
         },
      - createMessageOptional:
      {
         - count: 1,
         - max: 94.579,
         - mean: 94.579,
         - min: 94.579,
         - p50: 94.579,
         - p75: 94.579,
         - p95: 94.579,
         - p98: 94.579,
         - p99: 94.579,
         - p999: 94.579,
         - stddev: 0,
         - m15_rate: 10.678581251856285,
         - m1_rate: 2.0852873214053433,
         - m5_rate: 8.456257076624562,
         - mean_rate: 0.5343875445806129,
         - duration_units: "milliseconds",
         - rate_units: "calls/minute"
         },
      - getMessages:
      {
         - count: 3,
         - max: 9.809999999999999,
         - mean: 3.6413333333333333,
         - min: 0.514,
         - p50: 0.6,
         - p75: 9.809999999999999,
         - p95: 9.809999999999999,
         - p98: 9.809999999999999,
         - p99: 9.809999999999999,
         - p999: 9.809999999999999,
         - stddev: 5.342395093339066,
         - m15_rate: 0.18767034671569677,
         - m1_rate: 1.2185014871528328,
         - m5_rate: 0.49650226189858143,
         - mean_rate: 1.6030845484157583,
         - duration_units: "milliseconds",
         - rate_units: "calls/minute"
         },
      - getMetrics:
      {
         - count: 0,
         - max: 0,
         - mean: 0,
         - min: 0,
         - p50: 0,
         - p75: 0,
         - p95: 0,
         - p98: 0,
         - p99: 0,
         - p999: 0,
         - stddev: 0,
         - m15_rate: 0,
         - m1_rate: 0,
         - m5_rate: 0,
         - mean_rate: 0,
         - duration_units: "milliseconds",
         - rate_units: "calls/minute"
         }
      }

}






On Thu, Jul 3, 2014 at 9:28 AM, Bill O'Neil <bill at dartalley.com> wrote:

> I have mostly just been getting familiar with undertow for side projects.
>  I would be happy to share anything I come up with though to get some
> feedback.
>
>
> On Wed, Jul 2, 2014 at 10:44 AM, Jason Greene <jason.greene at redhat.com>
> wrote:
>
>> On Jul 2, 2014, at 9:02 AM, Bill O'Neil <bill at dartalley.com> wrote:
>>
>> > Is there any plan to open up an undertow-ext library where the
>> community can make small modules that hook into 3rd party dependencies?
>>  For example, an HttpHandler that uses Jackson/Gson to serialize to json
>> and set appropriate headers, or an HTML templating framework for rendering
>> HTML.
>> >
>> > Would you prefer these to be hosted by 3rd parties instead?
>>
>> I think this is a great idea. Are you interested in being a maintainer of
>> such a thing?
>>
>> --
>> 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/20140719/406c9cf2/attachment-0001.html 

From sdouglas at redhat.com  Wed Jul 23 02:46:14 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 23 Jul 2014 16:46:14 +1000
Subject: [undertow-dev] Undertow extensions library?
In-Reply-To: <CANd+gFzuPpy9Oqc0jYxK8x4CjgaBMhyx0p-hvUPWH-a_nWxD-w@mail.gmail.com>
References: <CANd+gFyH7mx38dt264UdaurS+aAOeXPQEim-i_wT3WKR_t4iCg@mail.gmail.com>
	<4129B9B4-BDA1-47C6-9358-3AE3162EFAD3@redhat.com>
	<CANd+gFzZ6GsEU0tsiLiU8jeC6_F5ggB+OxriScaapKpMYugKFw@mail.gmail.com>
	<CANd+gFzuPpy9Oqc0jYxK8x4CjgaBMhyx0p-hvUPWH-a_nWxD-w@mail.gmail.com>
Message-ID: <53CF5A36.8040608@redhat.com>

Sorry for the late reply, been very busy this week.

I had a look and so far I think it looks like a really good start, but I 
don't think this really belongs in the main Undertow repo (it would then 
need Java 8 to build for one thing, which I don't really want at this 
stage).


I'm still not sure where the best place to have these is, at the moment 
I am leaning towards a separate undertow-contrib repository, with a new 
repo for each component to allow them to be versioned separately.

Stuart

Bill O'Neil wrote:
> I had a few ideas I put together and would appreciate some feedback. A
> lot of it revolves around Java 8 but I kept all of the extensions
> themselves at Java 7. The main goal of Java 8 was to make constructing
> HttpHandlers easier when you delegate to other handlers.
>
> Example:
>
> Handlers.routing()
> .add(Methods.GET, "/messages", HandlerBuilder
>
> .create(CustomHandlers.json(Messages::getMessages))
>
> .wrap(CustomHandlers::timing, "getMessages")
>
> .wrap(BlockingHandler::new)
>
> .build())
>
> Here is my branch https://github.com/billoneil/undertow/tree/feature/ext
>
> Here is the entry point to an example that puts it all together.
> https://github.com/billoneil/undertow/blob/feature/ext/ext/examples/src/main/java/io/undertow/ext/examples/rest/RestServer.java
>
>
>
> Please excuse the boring example I couldn't think of anything
> interesting.
>
> If you run it locally
>
>
> curl -X POST localhost:8080/messages/optional -d '{"title": "Optional",
> "message": "Using optional"}'
> {"success":true}
>
> curl -X POST localhost:8080/messages/lambda -d '{"title": "Lambda",
> "message": "Using Lambda"}'
> {"success":true}
>
> curl -X POST localhost:8080/messages -d '{"title": "Method References",
> "message": "Using method references"}'
> {"success":true}
>
> curl -X GET localhost:8080/messages
> [
>
> *
> {
> o
> title: "Optional",
> o
> message: "Using optional"
> },
> *
> {
> o
> title: "Lambda",
> o
> message: "Using Lambda"
> },
> *
> {
> o
> title: "Method References",
> o
> message: "Using method references"
> }
>
> ]
>
> curl -X GET localhost:8080/info/metrics
> {
>
> *
> version: "3.0.0",
> *
> gauges: { },
> *
> counters: { },
> *
> histograms: { },
> *
> meters:
> {
> o
> response.status.code.200:
> {
> +
> count: 8,
> +
> m15_rate: 21.787938213503697,
> +
> m1_rate: 6.5304307794735275,
> +
> m5_rate: 18.017228623496,
> +
> mean_rate: 4.457584495510739,
> +
> units: "events/minute"
> }
> },
> *
> timers:
> {
> o
> createMessageLambda:
> {
> +
> count: 1,
> +
> max: 1.169,
> +
> mean: 1.169,
> +
> min: 1.169,
> +
> p50: 1.169,
> +
> p75: 1.169,
> +
> p95: 1.169,
> +
> p98: 1.169,
> +
> p99: 1.169,
> +
> p999: 1.169,
> +
> stddev: 0,
> +
> m15_rate: 0.059490549916151686,
> +
> m1_rate: 0.1812199126454006,
> +
> m5_rate: 0.14211865026090975,
> +
> mean_rate: 0.5343847126926461,
> +
> duration_units: "milliseconds",
> +
> rate_units: "calls/minute"
> },
> o
> createMessageMethodReferences:
> {
> +
> count: 1,
> +
> max: 0.648,
> +
> mean: 0.648,
> +
> min: 0.648,
> +
> p50: 0.648,
> +
> p75: 0.648,
> +
> p95: 0.648,
> +
> p98: 0.648,
> +
> p99: 0.648,
> +
> p999: 0.648,
> +
> stddev: 0,
> +
> m15_rate: 0.05982197273776584,
> +
> m1_rate: 0.19696865690816925,
> +
> m5_rate: 0.14450714325124409,
> +
> mean_rate: 0.5343791108783038,
> +
> duration_units: "milliseconds",
> +
> rate_units: "calls/minute"
> },
> o
> createMessageOptional:
> {
> +
> count: 1,
> +
> max: 94.579,
> +
> mean: 94.579,
> +
> min: 94.579,
> +
> p50: 94.579,
> +
> p75: 94.579,
> +
> p95: 94.579,
> +
> p98: 94.579,
> +
> p99: 94.579,
> +
> p999: 94.579,
> +
> stddev: 0,
> +
> m15_rate: 10.678581251856285,
> +
> m1_rate: 2.0852873214053433,
> +
> m5_rate: 8.456257076624562,
> +
> mean_rate: 0.5343875445806129,
> +
> duration_units: "milliseconds",
> +
> rate_units: "calls/minute"
> },
> o
> getMessages:
> {
> +
> count: 3,
> +
> max: 9.809999999999999,
> +
> mean: 3.6413333333333333,
> +
> min: 0.514,
> +
> p50: 0.6,
> +
> p75: 9.809999999999999,
> +
> p95: 9.809999999999999,
> +
> p98: 9.809999999999999,
> +
> p99: 9.809999999999999,
> +
> p999: 9.809999999999999,
> +
> stddev: 5.342395093339066,
> +
> m15_rate: 0.18767034671569677,
> +
> m1_rate: 1.2185014871528328,
> +
> m5_rate: 0.49650226189858143,
> +
> mean_rate: 1.6030845484157583,
> +
> duration_units: "milliseconds",
> +
> rate_units: "calls/minute"
> },
> o
> getMetrics:
> {
> +
> count: 0,
> +
> max: 0,
> +
> mean: 0,
> +
> min: 0,
> +
> p50: 0,
> +
> p75: 0,
> +
> p95: 0,
> +
> p98: 0,
> +
> p99: 0,
> +
> p999: 0,
> +
> stddev: 0,
> +
> m15_rate: 0,
> +
> m1_rate: 0,
> +
> m5_rate: 0,
> +
> mean_rate: 0,
> +
> duration_units: "milliseconds",
> +
> rate_units: "calls/minute"
> }
> }
>
> }
>
>
>
>
>
>
> On Thu, Jul 3, 2014 at 9:28 AM, Bill O'Neil <bill at dartalley.com
> <mailto:bill at dartalley.com>> wrote:
>
> I have mostly just been getting familiar with undertow for side
> projects. I would be happy to share anything I come up with though
> to get some feedback.
>
>
> On Wed, Jul 2, 2014 at 10:44 AM, Jason Greene
> <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> wrote:
>
> On Jul 2, 2014, at 9:02 AM, Bill O'Neil <bill at dartalley.com
> <mailto:bill at dartalley.com>> wrote:
>
> > Is there any plan to open up an undertow-ext library where
> the community can make small modules that hook into 3rd party
> dependencies? For example, an HttpHandler that uses
> Jackson/Gson to serialize to json and set appropriate headers,
> or an HTML templating framework for rendering HTML.
> >
> > Would you prefer these to be hosted by 3rd parties instead?
>
> I think this is a great idea. Are you interested in being a
> maintainer of such a thing?
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
>

From arjan.tijms at gmail.com  Fri Jul 25 10:49:30 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Fri, 25 Jul 2014 16:49:30 +0200
Subject: [undertow-dev] NPE in JASPIAuthenticationMechanism when using async
	requests
Message-ID: <CAE=-AhDVPgLJm7YTGYJGEy8D1NQTQK4w0yuu0_ySLoJsLALn0Q@mail.gmail.com>

Hi,

When using a basic async servlet, where the request processing is
transferred to an @Asynchronous method, there's a NPE at the end of the
request:

Exception in thread "default task-107" java.lang.NullPointerException
    at
org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism.wasAuthExceptionThrown(JASPIAuthenticationMechanism.java:164)
    at
org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism.access$100(JASPIAuthenticationMechanism.java:72)
    at
org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism$1.wrap(JASPIAuthenticationMechanism.java:240)
    at
org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism$1.wrap(JASPIAuthenticationMechanism.java:234)
    at
io.undertow.server.HttpServerExchange$WrapperStreamSinkConduitFactory.create(HttpServerExchange.java:2017)
    at
io.undertow.server.HttpServerExchange.getResponseChannel(HttpServerExchange.java:1167)
    at
io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:619)
    at
io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451)
    at
io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525)
    at
io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java:294)
    at
io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java:432)

The direct cause is that
JASPIAuthenticationMechanism#wasAuthExceptionThrown tries to access the
security context as-in the following line:

SecurityContextAssociation.getSecurityContext().getData().get(AuthException.class.getName())
!= null

Only, for an async request processing thread
SecurityContextAssociation.getSecurityContext() is always null, causing the
NPE. I created a test that functions as a reproducer here:
https://github.com/arjantijms/javaee7-samples/tree/master/jaspic/async-authentication
It also looks like there's something not entirely right with the async time
out on Undertow, but I haven't nailed that one down yet.

Kind regards,
Arjan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140725/c5a6b96d/attachment.html 

From ralf_boogie_blues at bluewin.ch  Sat Jul 26 09:30:09 2014
From: ralf_boogie_blues at bluewin.ch (ralf_boogie_blues at bluewin.ch)
Date: Sat, 26 Jul 2014 13:30:09 +0000 (GMT)
Subject: [undertow-dev] LoadBalancingProxyClient extensions
Message-ID: <28168257.35170.1406381409616.JavaMail.webmail@bluewin.ch>

Hi Undertow Developers
I am playing a little bit with the LoadBalancingProxyClient feature in Undertow. I am looking for a solution that replaces my implementation of a load balancer, which is based on Apache HttpClient.
The LoadBalancingProxyClient fulfills almost the functionality I need. Do you have a plan for these two features?
To make tho host selection configurable. Currently, it is a static round robin strategy. I think this is a simple task and I was able to change the code so that this host selection is configurable.
The second feature is much more difficult for me to solve. I need a failover to the next host also in case the backend server responds with say a status code 503. The backend servers are based on the clustered HA singleton pattern, meaning, there is one backend server which is the master node. The other backend servers are up but shouldn't get http request. If the inactive servers get a call, then they will respond with 503.  
We use Wildfly for front and backend servers. It would really cool to reuse all the undertow power:-)
Let me know what you think. I am certainly offer to help for whatever you need. Testing for example.
Regards,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140726/2e720894/attachment.html 

From sdouglas at redhat.com  Sun Jul 27 19:37:34 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 28 Jul 2014 09:37:34 +1000
Subject: [undertow-dev] NPE in JASPIAuthenticationMechanism when using
 async requests
In-Reply-To: <CAE=-AhDVPgLJm7YTGYJGEy8D1NQTQK4w0yuu0_ySLoJsLALn0Q@mail.gmail.com>
References: <CAE=-AhDVPgLJm7YTGYJGEy8D1NQTQK4w0yuu0_ySLoJsLALn0Q@mail.gmail.com>
Message-ID: <53D58D3E.3090008@redhat.com>

I think I have fixes for both these issues.

https://github.com/wildfly/wildfly/pull/6539/files

Should fix the NPE (I was not sure what security domain config your 
example needed in order to reproduce).

The timeout issues should be fixed in Undertow upstream, it looks like 
there was two issues:
- The timeout was running in an IO thread
- ThreadLocals where not being properly set up before dispatching to the 
error page

Stuart

arjan tijms wrote:
> Hi,
>
> When using a basic async servlet, where the request processing is
> transferred to an @Asynchronous method, there's a NPE at the end of the
> request:
>
> Exception in thread "default task-107" java.lang.NullPointerException
>      at
> org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism.wasAuthExceptionThrown(JASPIAuthenticationMechanism.java:164)
>      at
> org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism.access$100(JASPIAuthenticationMechanism.java:72)
>      at
> org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism$1.wrap(JASPIAuthenticationMechanism.java:240)
>      at
> org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism$1.wrap(JASPIAuthenticationMechanism.java:234)
>      at
> io.undertow.server.HttpServerExchange$WrapperStreamSinkConduitFactory.create(HttpServerExchange.java:2017)
>      at
> io.undertow.server.HttpServerExchange.getResponseChannel(HttpServerExchange.java:1167)
>      at
> io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:619)
>      at
> io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451)
>      at
> io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525)
>      at
> io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java:294)
>      at
> io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java:432)
>
> The direct cause is that
> JASPIAuthenticationMechanism#wasAuthExceptionThrown tries to access the
> security context as-in the following line:
>
> SecurityContextAssociation.getSecurityContext().getData().get(AuthException.class.getName())
> != null
>
> Only, for an async request processing thread
> SecurityContextAssociation.getSecurityContext() is always null, causing
> the NPE. I created a test that functions as a reproducer here:
> https://github.com/arjantijms/javaee7-samples/tree/master/jaspic/async-authentication
> It also looks like there's something not entirely right with the async
> time out on Undertow, but I haven't nailed that one down yet.
>
> Kind regards,
> Arjan
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From sdouglas at redhat.com  Sun Jul 27 19:40:12 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 28 Jul 2014 09:40:12 +1000
Subject: [undertow-dev] LoadBalancingProxyClient extensions
In-Reply-To: <28168257.35170.1406381409616.JavaMail.webmail@bluewin.ch>
References: <28168257.35170.1406381409616.JavaMail.webmail@bluewin.ch>
Message-ID: <53D58DDC.4030601@redhat.com>



ralf_boogie_blues at bluewin.ch wrote:
> Hi Undertow Developers
>
> I am playing a little bit with the LoadBalancingProxyClient feature in
> Undertow. I am looking for a solution that replaces my implementation of
> a load balancer, which is based on Apache HttpClient.
>
> The LoadBalancingProxyClient fulfills almost the functionality I need.
> Do you have a plan for these two features?
>
>  1. To make tho host selection configurable. Currently, it is a static
>     round robin strategy. I think this is a simple task and I was able
>     to change the code so that this host selection is configurable.

For now you can override the selectHost() method. Its not a great 
solution though. Can you file a JIRA to make this pluggable?

>
>  2. The second feature is much more difficult for me to solve. I need a
>     failover to the next host also in case the backend server responds
>     with say a status code 503. The backend servers are based on the
>     clustered HA singleton pattern, meaning, there is one backend server
>     which is the master node. The other backend servers are up but
>     shouldn't get http request. If the inactive servers get a call, then
>     they will respond with 503.

Can you file a JIRA about this as well?

At the moment our focus with the proxy is getting mod_cluster support up 
and working, however both these things should be relatively easy to 
implement.

Stuart

>
> We use Wildfly for front and backend servers. It would really cool to
> reuse all the undertow power:-)
>
> Let me know what you think. I am certainly offer to help for whatever
> you need. Testing for example.
>
> Regards,
> Ralf
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From arjan.tijms at gmail.com  Mon Jul 28 05:38:50 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Mon, 28 Jul 2014 11:38:50 +0200
Subject: [undertow-dev] NPE in JASPIAuthenticationMechanism when using
 async requests
In-Reply-To: <53D58D3E.3090008@redhat.com>
References: <CAE=-AhDVPgLJm7YTGYJGEy8D1NQTQK4w0yuu0_ySLoJsLALn0Q@mail.gmail.com>
	<53D58D3E.3090008@redhat.com>
Message-ID: <CAE=-AhBcD5BAJkdvLa7shu+ndqEcx0ST59H4HdzvQvhHWcew=w@mail.gmail.com>

Hi,


On Mon, Jul 28, 2014 at 1:37 AM, Stuart Douglas <sdouglas at redhat.com> wrote:

> I think I have fixes for both these issues.
>
> https://github.com/wildfly/wildfly/pull/6539/files
>
> Should fix the NPE (I was not sure what security domain config your
> example needed in order to reproduce).
>

Okay great, I'll give it a shot. The security domain configured in
standalone.xml is a dummy one that's unfortunately needed to trick Undertow
into activating JASPIC (it shouldn't be needed, but for now it is). It's
the following one that's used I think in pretty much all WildFly JASPIC
examples:

<security-domain name="jaspitest" cache-type="default">
    <authentication-jaspi>
        <login-module-stack name="dummy">
            <login-module code="Dummy" flag="optional"/>
        </login-module-stack>
        <auth-module code="Dummy"/>
    </authentication-jaspi>
</security-domain>



> The timeout issues should be fixed in Undertow upstream, it looks like
> there was two issues:
> - The timeout was running in an IO thread
> - ThreadLocals where not being properly set up before dispatching to the
> error page
>

This sounds like it could well be the issue I was seeing. Timeout was
indeed running in an IO thread and it for some reason didn't see that the
response was committed and/or dispatched, even when asyncContext.complete()
had been called.

Regards,
Arjan



>
> Stuart
>
> arjan tijms wrote:
>
>> Hi,
>>
>> When using a basic async servlet, where the request processing is
>> transferred to an @Asynchronous method, there's a NPE at the end of the
>> request:
>>
>> Exception in thread "default task-107" java.lang.NullPointerException
>>      at
>> org.wildfly.extension.undertow.security.jaspi.
>> JASPIAuthenticationMechanism.wasAuthExceptionThrown(
>> JASPIAuthenticationMechanism.java:164)
>>      at
>> org.wildfly.extension.undertow.security.jaspi.
>> JASPIAuthenticationMechanism.access$100(JASPIAuthenticationMechanism.
>> java:72)
>>      at
>> org.wildfly.extension.undertow.security.jaspi.
>> JASPIAuthenticationMechanism$1.wrap(JASPIAuthenticationMechanism.
>> java:240)
>>      at
>> org.wildfly.extension.undertow.security.jaspi.
>> JASPIAuthenticationMechanism$1.wrap(JASPIAuthenticationMechanism.
>> java:234)
>>      at
>> io.undertow.server.HttpServerExchange$WrapperStreamSinkConduitFactor
>> y.create(HttpServerExchange.java:2017)
>>      at
>> io.undertow.server.HttpServerExchange.getResponseChannel(
>> HttpServerExchange.java:1167)
>>      at
>> io.undertow.servlet.spec.ServletOutputStreamImpl.close(
>> ServletOutputStreamImpl.java:619)
>>      at
>> io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(
>> HttpServletResponseImpl.java:451)
>>      at
>> io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(
>> HttpServletResponseImpl.java:525)
>>      at
>> io.undertow.servlet.spec.AsyncContextImpl$3.run(
>> AsyncContextImpl.java:294)
>>      at
>> io.undertow.servlet.spec.AsyncContextImpl$6.run(
>> AsyncContextImpl.java:432)
>>
>> The direct cause is that
>> JASPIAuthenticationMechanism#wasAuthExceptionThrown tries to access the
>> security context as-in the following line:
>>
>> SecurityContextAssociation.getSecurityContext().getData()
>> .get(AuthException.class.getName())
>> != null
>>
>> Only, for an async request processing thread
>> SecurityContextAssociation.getSecurityContext() is always null, causing
>> the NPE. I created a test that functions as a reproducer here:
>> https://github.com/arjantijms/javaee7-samples/tree/master/
>> jaspic/async-authentication
>> It also looks like there's something not entirely right with the async
>> time out on Undertow, but I haven't nailed that one down yet.
>>
>> Kind regards,
>> Arjan
>>
>>
>> _______________________________________________
>> 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/20140728/ddad0403/attachment-0001.html 

From ralf_boogie_blues at bluewin.ch  Mon Jul 28 12:31:53 2014
From: ralf_boogie_blues at bluewin.ch (ralf_boogie_blues at bluewin.ch)
Date: Mon, 28 Jul 2014 16:31:53 +0000 (GMT)
Subject: [undertow-dev] LoadBalancingProxyClient extensions
In-Reply-To: <53D58DDC.4030601@redhat.com>
References: <28168257.35170.1406381409616.JavaMail.webmail@bluewin.ch>
	<53D58DDC.4030601@redhat.com>
Message-ID: <14290127.33811.1406565113941.JavaMail.webmail@bluewin.ch>

Thanks Stuart

I have created:

UNDERTOW-289
UNDERTOW-290

Let me know if I can help in case your are busy with the mod-cluster features. 

Regards,
Ralf


----Urspr?ngliche Nachricht----
Von : sdouglas at redhat.com
Datum : 28/07/2014 - 01:40 (CEST)
An : ralf_boogie_blues at bluewin.ch
Cc : undertow-dev at lists.jboss.org
Betreff : Re: [undertow-dev] LoadBalancingProxyClient extensions



ralf_boogie_blues at bluewin.ch wrote:
> Hi Undertow Developers
>
> I am playing a little bit with the LoadBalancingProxyClient feature in
> Undertow. I am looking for a solution that replaces my implementation of
> a load balancer, which is based on Apache HttpClient.
>
> The LoadBalancingProxyClient fulfills almost the functionality I need.
> Do you have a plan for these two features?
>
>  1. To make tho host selection configurable. Currently, it is a static
>     round robin strategy. I think this is a simple task and I was able
>     to change the code so that this host selection is configurable.

For now you can override the selectHost() method. Its not a great 
solution though. Can you file a JIRA to make this pluggable?

>
>  2. The second feature is much more difficult for me to solve. I need a
>     failover to the next host also in case the backend server responds
>     with say a status code 503. The backend servers are based on the
>     clustered HA singleton pattern, meaning, there is one backend server
>     which is the master node. The other backend servers are up but
>     shouldn't get http request. If the inactive servers get a call, then
>     they will respond with 503.

Can you file a JIRA about this as well?

At the moment our focus with the proxy is getting mod_cluster support up 
and working, however both these things should be relatively easy to 
implement.

Stuart

>
> We use Wildfly for front and backend servers. It would really cool to
> reuse all the undertow power:-)
>
> Let me know what you think. I am certainly offer to help for whatever
> you need. Testing for example.
>
> Regards,
> Ralf
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev



From miere.teixeira at gmail.com  Tue Jul 29 08:17:26 2014
From: miere.teixeira at gmail.com (Miere Teixeira)
Date: Tue, 29 Jul 2014 09:17:26 -0300
Subject: [undertow-dev] Make Credential on IdentityManager be a generic
	parameter
Message-ID: <CAHezjrTNhq38DDSyA+DpVavwzvb0AOMqK0=sbA_5R-OmzMUAPA@mail.gmail.com>

Hi devs,
how you doing?

I was checking out the security API proposed by Undertow and I've
identified that io.undertow.security.idm.IdentityManager receive an empty
credential as parameter in two of its methods. After taking a look into the
Java Docs and the exemple codes I figure out why.

As proposed in the original design, an IdentityManager should know which
kind of credential was created by the AuthenticationMechanism, cast it, and
then apply the desired identity match. It means that there's an existance
relation between both IdentityManager and AuthenticationMechanism.

Maybe, making Credential a generic parameter of IdentityManager it will
make IdentityManager more plugable. It also forces us the improve
SecurityContext with this new design.

A little sample copied from BasicAuthenticationMechanism.java[106~110] as
an exemple.

final IdentityManager<PasswordCredential> idm =
> securityContext.getIdentityManagerFor( PasswordCredential.class );
> final PasswordCredential credential = new PasswordCredential(password);
> try {
>     final AuthenticationMechanismOutcome result;
>     Account account = idm.verify(userName, credential);
>

Let me know if this makes sense for Undertow needs!

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140729/7e1010c9/attachment.html 

From darran.lofthouse at jboss.com  Wed Jul 30 06:14:19 2014
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 30 Jul 2014 11:14:19 +0100
Subject: [undertow-dev] Make Credential on IdentityManager be a generic
 parameter
In-Reply-To: <CAHezjrTNhq38DDSyA+DpVavwzvb0AOMqK0=sbA_5R-OmzMUAPA@mail.gmail.com>
References: <CAHezjrTNhq38DDSyA+DpVavwzvb0AOMqK0=sbA_5R-OmzMUAPA@mail.gmail.com>
Message-ID: <53D8C57B.8050104@jboss.com>

Hello Miere,

Thank you very much for your comments, at the moment we are actually 
working on another project called wildfly-elytron - at a high level this 
project is providing APIs and SPIs to allow different identity providers 
to be plugged into WildFly for integration with authentication mechanisms.

We haven't started to touch Undertow yet but fairly soon we will need to 
start reviewing the integration with Undertow which will be impacting on 
the area you highlight here.

FYI negotiating supported credential types and strongly types 
acquisition of them is central to Elytron.

Regards,
Darran Lofthouse.


On 29/07/14 13:17, Miere Teixeira wrote:
> Hi devs,
> how you doing?
>
> I was checking out the security API proposed by Undertow and I've
> identified that io.undertow.security.idm.IdentityManager receive an
> empty credential as parameter in two of its methods. After taking a look
> into the Java Docs and the exemple codes I figure out why.
>
> As proposed in the original design, an IdentityManager should know which
> kind of credential was created by the AuthenticationMechanism, cast it,
> and then apply the desired identity match. It means that there's an
> existance relation between both IdentityManager and AuthenticationMechanism.
>
> Maybe, making Credential a generic parameter of IdentityManager it will
> make IdentityManager more plugable. It also forces us the improve
> SecurityContext with this new design.
>
> A little sample copied from BasicAuthenticationMechanism.java[106~110]
> as an exemple.
>
>     final IdentityManager<PasswordCredential> idm =
>     securityContext.getIdentityManagerFor( PasswordCredential.class );
>     final PasswordCredential credential = new PasswordCredential(password);
>     try {
>          final AuthenticationMechanismOutcome result;
>          Account account = idm.verify(userName, credential);
>
>
> Let me know if this makes sense for Undertow needs!
>
> Regards
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>

From miere.teixeira at gmail.com  Wed Jul 30 07:56:32 2014
From: miere.teixeira at gmail.com (Miere Teixeira)
Date: Wed, 30 Jul 2014 08:56:32 -0300
Subject: [undertow-dev] Make Credential on IdentityManager be a generic
	parameter
In-Reply-To: <53D8C57B.8050104@jboss.com>
References: <CAHezjrTNhq38DDSyA+DpVavwzvb0AOMqK0=sbA_5R-OmzMUAPA@mail.gmail.com>
	<53D8C57B.8050104@jboss.com>
Message-ID: <CAHezjrT0YNTPT+zfT_gZfnHaVfZg3eWBF0f8_NwF0dr9H4SoxA@mail.gmail.com>

Thank you for your answer, Darran
Its nice to see the community moving forward so fast.

Let me know if you guys need help with something during this development.
I'm really interested in make Undertow run standalone for my customers
as a lightweight container. Authentication and Authorization is the only
missing gap here.

Regards,
Miere Teixeira


On Wed, Jul 30, 2014 at 7:14 AM, Darran Lofthouse <
darran.lofthouse at jboss.com> wrote:

> Hello Miere,
>
> Thank you very much for your comments, at the moment we are actually
> working on another project called wildfly-elytron - at a high level this
> project is providing APIs and SPIs to allow different identity providers
> to be plugged into WildFly for integration with authentication mechanisms.
>
> We haven't started to touch Undertow yet but fairly soon we will need to
> start reviewing the integration with Undertow which will be impacting on
> the area you highlight here.
>
> FYI negotiating supported credential types and strongly types
> acquisition of them is central to Elytron.
>
> Regards,
> Darran Lofthouse.
>
>
> On 29/07/14 13:17, Miere Teixeira wrote:
> > Hi devs,
> > how you doing?
> >
> > I was checking out the security API proposed by Undertow and I've
> > identified that io.undertow.security.idm.IdentityManager receive an
> > empty credential as parameter in two of its methods. After taking a look
> > into the Java Docs and the exemple codes I figure out why.
> >
> > As proposed in the original design, an IdentityManager should know which
> > kind of credential was created by the AuthenticationMechanism, cast it,
> > and then apply the desired identity match. It means that there's an
> > existance relation between both IdentityManager and
> AuthenticationMechanism.
> >
> > Maybe, making Credential a generic parameter of IdentityManager it will
> > make IdentityManager more plugable. It also forces us the improve
> > SecurityContext with this new design.
> >
> > A little sample copied from BasicAuthenticationMechanism.java[106~110]
> > as an exemple.
> >
> >     final IdentityManager<PasswordCredential> idm =
> >     securityContext.getIdentityManagerFor( PasswordCredential.class );
> >     final PasswordCredential credential = new
> PasswordCredential(password);
> >     try {
> >          final AuthenticationMechanismOutcome result;
> >          Account account = idm.verify(userName, credential);
> >
> >
> > Let me know if this makes sense for Undertow needs!
> >
> > Regards
> >
> >
> > _______________________________________________
> > 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/20140730/5bdfbf49/attachment.html