11:31 a.m.
I need to create a separate adapter distro for Wildfly 10 as it is not
compatible with Wildfly 8 and 9. To do this, I need an explanation of
the distribution directory for adapters
distribution/adapters/wildfly-adapter? What is this for? Wildfly 9 and 10?
distribution/feature-packs/adapter-feature-pack? What is this for?
Wildfly 10 only? Wildfly 9 and 10?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12:43 p.m.
On 21 January 2016 at 18:31, Bill Burke <bburke(a)redhat.com> wrote:
I need to create a separate adapter distro for Wildfly 10 as it is
not
compatible with Wildfly 8 and 9. To do this, I need an explanation of
the distribution directory for adapters
Would it not be cleaner to incorporate something in the adapter that uses
different classes depending on the undertow version?
distribution/adapters/wildfly-adapter? What is this for? Wildfly 9 and
10?
distribution/adapters/wildfly-adapter is for the latests range we support.
Currently it was supposed to be WF9 + 10. The idea was
that distribution/adapters/wildfly-adapter would always be for the latest
version of WildFly. When we have to do something that prevents backwards
compatibility we'd copy it to distribution/adapters/wf-<VERSION> and then
update distribution/adapters/wildfly-adapter to the latest WF version.
distribution/feature-packs/adapter-feature-pack? What is this for?
Wildfly 10 only? Wildfly 9 and 10?
distribution/feature-packs/adapter-feature-pack only has to support latest
version of WF. It's only used by WildFly Swarm guys.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:11 p.m.
On 1/21/2016 1:43 PM, Stian Thorgersen wrote:
On 21 January 2016 at 18:31, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
I need to create a separate adapter distro for Wildfly 10 as it is not
compatible with Wildfly 8 and 9. To do this, I need an explanation of
the distribution directory for adapters
Would it not be cleaner to incorporate something in the adapter that
uses different classes depending on the undertow version?
No idea what you mean. The undertow class/method in question has a
different signature between 8-9 and 10. The method call has parameters
whose types don't exist in one or the other's versions. Basically I'll
be creating a wildfly10-adapter-spi and wildfly9-adapter-spi jar that
each have one class in them. These modules are included in the
adapter-spi module. I just don't see any way around that.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
1:19 p.m.
What I mean is:
if
(TheProblemClass.class.getMethod("..").getParameterTypes()[0].equals(SomeObject.class))
{
return new WildFly9Impl();
} else {
return new WildFly10Impl();
}
Is that not simpler and easier for users than creating a whole new adapter
dist?
On 21 January 2016 at 20:11, Bill Burke <bburke(a)redhat.com> wrote:
On 1/21/2016 1:43 PM, Stian Thorgersen wrote:
On 21 January 2016 at 18:31, Bill Burke <bburke(a)redhat.com> wrote:
> I need to create a separate adapter distro for Wildfly 10 as it is not
> compatible with Wildfly 8 and 9. To do this, I need an explanation of
> the distribution directory for adapters
>
Would it not be cleaner to incorporate something in the adapter that uses
different classes depending on the undertow version?
No idea what you mean. The undertow class/method in question has a
different signature between 8-9 and 10. The method call has parameters
whose types don't exist in one or the other's versions. Basically I'll be
creating a wildfly10-adapter-spi and wildfly9-adapter-spi jar that each
have one class in them. These modules are included in the adapter-spi
module. I just don't see any way around that.
--
Bill Burke
JBoss, a division of Red Hathttp://bill.burkecentral.com
1:27 p.m.
You still have to have different jars as how would Wildfly9Impl and
Wildfly10Impl compile? Again, the type parameters used in Wildfly9
don't exist in 10. The ones used in 10 don't exist in 9.
On 1/21/2016 2:19 PM, Stian Thorgersen wrote:
What I mean is:
if
(TheProblemClass.class.getMethod("..").getParameterTypes()[0].equals(SomeObject.class))
{
return new WildFly9Impl();
} else {
return new WildFly10Impl();
}
Is that not simpler and easier for users than creating a whole new
adapter dist?
On 21 January 2016 at 20:11, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
On 1/21/2016 1:43 PM, Stian Thorgersen wrote:
>
>
> On 21 January 2016 at 18:31, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> I need to create a separate adapter distro for Wildfly 10 as
> it is not
> compatible with Wildfly 8 and 9. To do this, I need an
> explanation of
> the distribution directory for adapters
>
>
> Would it not be cleaner to incorporate something in the adapter
> that uses different classes depending on the undertow version?
No idea what you mean. The undertow class/method in question has
a different signature between 8-9 and 10. The method call has
parameters whose types don't exist in one or the other's versions.
Basically I'll be creating a wildfly10-adapter-spi and
wildfly9-adapter-spi jar that each have one class in them. These
modules are included in the adapter-spi module. I just don't see
any way around that.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
1:37 p.m.
True, didn't consider that. We could do it with Infinispan because the
methods where actually there, just didn't work on the old version.
I can't see any other option then. Sucks to have to maintain all this
different versions of the adapters.
On 21 January 2016 at 20:27, Bill Burke <bburke(a)redhat.com> wrote:
You still have to have different jars as how would Wildfly9Impl and
Wildfly10Impl compile? Again, the type parameters used in Wildfly9 don't
exist in 10. The ones used in 10 don't exist in 9.
On 1/21/2016 2:19 PM, Stian Thorgersen wrote:
What I mean is:
if
(TheProblemClass.class.getMethod("..").getParameterTypes()[0].equals(SomeObject.class))
{
return new WildFly9Impl();
} else {
return new WildFly10Impl();
}
Is that not simpler and easier for users than creating a whole new adapter
dist?
On 21 January 2016 at 20:11, Bill Burke <bburke(a)redhat.com> wrote:
>
>
> On 1/21/2016 1:43 PM, Stian Thorgersen wrote:
>
>
>
> On 21 January 2016 at 18:31, Bill Burke < <bburke(a)redhat.com>
> bburke(a)redhat.com> wrote:
>
>> I need to create a separate adapter distro for Wildfly 10 as it is not
>> compatible with Wildfly 8 and 9. To do this, I need an explanation of
>> the distribution directory for adapters
>>
>
> Would it not be cleaner to incorporate something in the adapter that uses
> different classes depending on the undertow version?
>
>
> No idea what you mean. The undertow class/method in question has a
> different signature between 8-9 and 10. The method call has parameters
> whose types don't exist in one or the other's versions. Basically I'll
be
> creating a wildfly10-adapter-spi and wildfly9-adapter-spi jar that each
> have one class in them. These modules are included in the adapter-spi
> module. I just don't see any way around that.
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
--
Bill Burke
JBoss, a division of Red Hathttp://bill.burkecentral.com
2:15 p.m.
I'm working an adapter based on WildFly Elytron's SPI. In theory, you would be
able to implement Elytron's SPI once and have it supported in different WildFly
versions.
----- Original Message -----
From: "Stian Thorgersen" <sthorger(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Thursday, January 21, 2016 5:37:48 PM
Subject: Re: [keycloak-dev] need explanation of distribution for adapters
True, didn't consider that. We could do it with Infinispan because the methods where
actually there, just didn't work on the old version.
I can't see any other option then. Sucks to have to maintain all this different
versions of the adapters.
On 21 January 2016 at 20:27, Bill Burke < bburke(a)redhat.com > wrote:
You still have to have different jars as how would Wildfly9Impl and Wildfly10Impl compile?
Again, the type parameters used in Wildfly9 don't exist in 10. The ones used in 10
don't exist in 9.
On 1/21/2016 2:19 PM, Stian Thorgersen wrote:
What I mean is:
if
(TheProblemClass.class.getMethod("..").getParameterTypes()[0].equals(SomeObject.class))
{
return new WildFly9Impl();
} else {
return new WildFly10Impl();
}
Is that not simpler and easier for users than creating a whole new adapter dist?
On 21 January 2016 at 20:11, Bill Burke < bburke(a)redhat.com > wrote:
On 1/21/2016 1:43 PM, Stian Thorgersen wrote:
On 21 January 2016 at 18:31, Bill Burke < bburke(a)redhat.com > wrote:
I need to create a separate adapter distro for Wildfly 10 as it is not
compatible with Wildfly 8 and 9. To do this, I need an explanation of
the distribution directory for adapters
Would it not be cleaner to incorporate something in the adapter that uses different
classes depending on the undertow version?
No idea what you mean. The undertow class/method in question has a different signature
between 8-9 and 10. The method call has parameters whose types don't exist in one or
the other's versions. Basically I'll be creating a wildfly10-adapter-spi and
wildfly9-adapter-spi jar that each have one class in them. These modules are included in
the adapter-spi module. I just don't see any way around that.
--
Bill Burke
JBoss, a division of Red Hat http://bill.burkecentral.com
--
Bill Burke
JBoss, a division of Red Hat http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:17 p.m.
Of course I find a better solution after whining and complaing...Its
still a hack, but, it is portable.
On 1/21/2016 2:37 PM, Stian Thorgersen wrote:
True, didn't consider that. We could do it with Infinispan
because the
methods where actually there, just didn't work on the old version.
I can't see any other option then. Sucks to have to maintain all this
different versions of the adapters.
On 21 January 2016 at 20:27, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
You still have to have different jars as how would Wildfly9Impl
and Wildfly10Impl compile? Again, the type parameters used in
Wildfly9 don't exist in 10. The ones used in 10 don't exist in 9.
On 1/21/2016 2:19 PM, Stian Thorgersen wrote:
> What I mean is:
>
> if
>
(TheProblemClass.class.getMethod("..").getParameterTypes()[0].equals(SomeObject.class))
> {
> return new WildFly9Impl();
> } else {
> return new WildFly10Impl();
> }
>
> Is that not simpler and easier for users than creating a whole
> new adapter dist?
>
> On 21 January 2016 at 20:11, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
>
>
> On 1/21/2016 1:43 PM, Stian Thorgersen wrote:
>>
>>
>> On 21 January 2016 at 18:31, Bill Burke <bburke(a)redhat.com
>> <mailto:bburke@redhat.com>> wrote:
>>
>> I need to create a separate adapter distro for Wildfly
>> 10 as it is not
>> compatible with Wildfly 8 and 9. To do this, I need an
>> explanation of
>> the distribution directory for adapters
>>
>>
>> Would it not be cleaner to incorporate something in the
>> adapter that uses different classes depending on the
>> undertow version?
>
> No idea what you mean. The undertow class/method in
> question has a different signature between 8-9 and 10. The
> method call has parameters whose types don't exist in one or
> the other's versions. Basically I'll be creating a
> wildfly10-adapter-spi and wildfly9-adapter-spi jar that each
> have one class in them. These modules are included in the
> adapter-spi module. I just don't see any way around that.
>
> --
> 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
2:04 a.m.
It's always good to whine and complain a bit :)
On 21 January 2016 at 23:17, Bill Burke <bburke(a)redhat.com> wrote:
Of course I find a better solution after whining and complaing...Its
still
a hack, but, it is portable.
On 1/21/2016 2:37 PM, Stian Thorgersen wrote:
True, didn't consider that. We could do it with Infinispan because the
methods where actually there, just didn't work on the old version.
I can't see any other option then. Sucks to have to maintain all this
different versions of the adapters.
On 21 January 2016 at 20:27, Bill Burke <bburke(a)redhat.com> wrote:
> You still have to have different jars as how would Wildfly9Impl and
> Wildfly10Impl compile? Again, the type parameters used in Wildfly9 don't
> exist in 10. The ones used in 10 don't exist in 9.
>
>
> On 1/21/2016 2:19 PM, Stian Thorgersen wrote:
>
> What I mean is:
>
> if
>
(TheProblemClass.class.getMethod("..").getParameterTypes()[0].equals(SomeObject.class))
> {
> return new WildFly9Impl();
> } else {
> return new WildFly10Impl();
> }
>
> Is that not simpler and easier for users than creating a whole new
> adapter dist?
>
> On 21 January 2016 at 20:11, Bill Burke < <bburke(a)redhat.com>
> bburke(a)redhat.com> wrote:
>
>>
>>
>> On 1/21/2016 1:43 PM, Stian Thorgersen wrote:
>>
>>
>>
>> On 21 January 2016 at 18:31, Bill Burke < <bburke(a)redhat.com>
>> bburke(a)redhat.com> wrote:
>>
>>> I need to create a separate adapter distro for Wildfly 10 as it is not
>>> compatible with Wildfly 8 and 9. To do this, I need an explanation of
>>> the distribution directory for adapters
>>>
>>
>> Would it not be cleaner to incorporate something in the adapter that
>> uses different classes depending on the undertow version?
>>
>>
>> No idea what you mean. The undertow class/method in question has a
>> different signature between 8-9 and 10. The method call has parameters
>> whose types don't exist in one or the other's versions. Basically
I'll be
>> creating a wildfly10-adapter-spi and wildfly9-adapter-spi jar that each
>> have one class in them. These modules are included in the adapter-spi
>> module. I just don't see any way around that.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
--
Bill Burke
JBoss, a division of Red Hathttp://bill.burkecentral.com
3639
days inactive
3640
days old
8 comments
3 participants
participants (3)
-
Bill Burke -
Pedro Igor Silva -
Stian Thorgersen