5:51 a.m.
I have been looking at the steps required to migrate the WildFly Elytron
integration to Undertow 3 from Undertow 2.
Overall it seems minimal changes are required but I was thinking if there
could be an opportunity to evolve the API within Undertow 2 making
migration to 3 easier in the future.
One example being on SSSessionInfo we make use of the following method: -
void renegotiate(HttpServerExchange exchange, SslClientAuthMode
sslClientAuthMode) throws IOException;
which has now been changed to: -
void renegotiate(HttpServerExchange exchange, ClientAuth sslClientAuthMode)
throws IOException;
The first form is making use of Xnio API and the second is using Netty API.
If this was deprecated in Undertow 2 and a pure Undertow variant added it
could be usable both in 2 and 3.
I suspect a number of the other changes breaking API compatibility could be
handled in a similar way.
Regards,
Darran Lofthouse.
5:42 p.m.
On Mon, Apr 15, 2019 at 8:59 PM Darran Lofthouse <darran.lofthouse(a)jboss.com>
wrote:
I have been looking at the steps required to migrate the WildFly
Elytron
integration to Undertow 3 from Undertow 2.
Overall it seems minimal changes are required but I was thinking if there
could be an opportunity to evolve the API within Undertow 2 making
migration to 3 easier in the future.
One example being on SSSessionInfo we make use of the following method: -
void renegotiate(HttpServerExchange exchange, SslClientAuthMode
sslClientAuthMode) throws IOException;
which has now been changed to: -
void renegotiate(HttpServerExchange exchange, ClientAuth
sslClientAuthMode) throws IOException;
The first form is making use of Xnio API and the second is using Netty API.
If this was deprecated in Undertow 2 and a pure Undertow variant added it
could be usable both in 2 and 3.
This is a good idea. If you see areas where this can be done can you file a
JIRA (or better yet open a PR)?
In this case I think we should get rid of the Netty one entirely, and just
have an agnostic one.
Maybe we also need an Undertow 2.1 branch, which will aim to improve
compatibility by adding methods like this that will work in both versions.
Stuart
I suspect a number of the other changes breaking API compatibility could
be handled in a similar way.
Regards,
Darran Lofthouse.
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
3:48 a.m.
On Mon, Apr 15, 2019 at 11:42 PM Stuart Douglas <sdouglas(a)redhat.com> wrote:
This is a good idea. If you see areas where this can be done can you file
a JIRA (or better yet open a PR)?
Will start to get some PRs in - I think the executors are the hardest
change but will start with these as I find them.
In this case I think we should get rid of the Netty one entirely, and
just
have an agnostic one.
+1 I think once we have agnostic alternatives remove the Netty specifics
from Undertow 3.
Maybe we also need an Undertow 2.1 branch, which will aim to improve
compatibility by adding methods like this that will work in both versions.
What is the policy regarding adding new API in 2.0 if this approach needs a
minor version increment may be useful to get something started.
Stuart
>
> I suspect a number of the other changes breaking API compatibility could
> be handled in a similar way.
>
> Regards,
> Darran Lofthouse.
>
>
>
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
3:58 a.m.
On Tue, Apr 16, 2019 at 6:49 PM Darran Lofthouse <darran.lofthouse(a)jboss.com>
wrote:
On Mon, Apr 15, 2019 at 11:42 PM Stuart Douglas <sdouglas(a)redhat.com>
wrote:
>
> This is a good idea. If you see areas where this can be done can you file
> a JIRA (or better yet open a PR)?
>
Will start to get some PRs in - I think the executors are the hardest
change but will start with these as I find them.
> In this case I think we should get rid of the Netty one entirely, and
> just have an agnostic one.
>
+1 I think once we have agnostic alternatives remove the Netty specifics
from Undertow 3.
> Maybe we also need an Undertow 2.1 branch, which will aim to improve
> compatibility by adding methods like this that will work in both versions.
>
What is the policy regarding adding new API in 2.0 if this approach needs
a minor version increment may be useful to get something started.
We have added new methods in micros before, but if we are doing a big chunk
of them we should target 2.1.
Stuart
>
> Stuart
>
>
>>
>> I suspect a number of the other changes breaking API compatibility could
>> be handled in a similar way.
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>>
>>
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
4:05 a.m.
Ok, we we start to get PRs in and hold them back we can review how big a
change we think this would become and apply to 2.1.
On Tue, Apr 16, 2019 at 9:58 AM Stuart Douglas <sdouglas(a)redhat.com> wrote:
On Tue, Apr 16, 2019 at 6:49 PM Darran Lofthouse <
darran.lofthouse(a)jboss.com> wrote:
>
>
> On Mon, Apr 15, 2019 at 11:42 PM Stuart Douglas <sdouglas(a)redhat.com>
> wrote:
>
>>
>> This is a good idea. If you see areas where this can be done can you
>> file a JIRA (or better yet open a PR)?
>>
>
> Will start to get some PRs in - I think the executors are the hardest
> change but will start with these as I find them.
>
>
>> In this case I think we should get rid of the Netty one entirely, and
>> just have an agnostic one.
>>
>
> +1 I think once we have agnostic alternatives remove the Netty specifics
> from Undertow 3.
>
>
>> Maybe we also need an Undertow 2.1 branch, which will aim to improve
>> compatibility by adding methods like this that will work in both versions.
>>
>
> What is the policy regarding adding new API in 2.0 if this approach needs
> a minor version increment may be useful to get something started.
>
We have added new methods in micros before, but if we are doing a big
chunk of them we should target 2.1.
Stuart
>
>
>>
>> Stuart
>>
>>
>>>
>>> I suspect a number of the other changes breaking API compatibility
>>> could be handled in a similar way.
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>>
2106
days inactive
2107
days old
4 comments
2 participants
participants (2)
-
Darran Lofthouse -
Stuart Douglas