Removing JAXR & backward compatiblity

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Removing JAXR & backward compatiblity

Thomas Diesler
Folks, 

related to 

* [AS7-6612] Remove JAXR support

I'd like to know whether we need to preserve backward compatibility of the configuration and if so what should happen if there is a jaxr config item? Generally, can AS8 break backward compatibility with respect to the config?

cheers
--thomas
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx 




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing JAXR & backward compatiblity

David Lloyd-2
On 02/28/2013 05:57 AM, Thomas Diesler wrote:

> Folks,
>
> related to
>
> * [AS7-6612 <https://issues.jboss.org/browse/AS7-6612>] Remove JAXR support
>
> I'd like to know whether we need to preserve backward compatibility of
> the configuration and if so what should happen if there is a jaxr config
> item? Generally, can AS8 break backward compatibility with respect to
> the config?

Brian points out that we don't have a specific requirement to maintain
compatibility with obsolete subsystems.  I think we could go ahead with
the removal (granted part of the reason I feel this way is that I've
already removed JSR-88...).

Going forward though Kabir suggested that if we do want to, say, allow
7.x instances to be managed from an 8.x DC, that we should create "stub"
extensions for the removed stuff that only carry and validate
configuration but aren't actually supported on 8.x servers.  This seems
like a valid possibility to me.
--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing JAXR & backward compatiblity

Thomas Diesler
Ok, stub extensions is the obvious alternative to breaking compatibility. I'll leave this as a future task and create a jira for it if that's ok with you.

cheers
--thomas

On Feb 28, 2013, at 4:22 PM, David M. Lloyd <[hidden email]> wrote:

> On 02/28/2013 05:57 AM, Thomas Diesler wrote:
>> Folks,
>>
>> related to
>>
>> * [AS7-6612 <https://issues.jboss.org/browse/AS7-6612>] Remove JAXR support
>>
>> I'd like to know whether we need to preserve backward compatibility of
>> the configuration and if so what should happen if there is a jaxr config
>> item? Generally, can AS8 break backward compatibility with respect to
>> the config?
>
> Brian points out that we don't have a specific requirement to maintain
> compatibility with obsolete subsystems.  I think we could go ahead with
> the removal (granted part of the reason I feel this way is that I've
> already removed JSR-88...).
>
> Going forward though Kabir suggested that if we do want to, say, allow
> 7.x instances to be managed from an 8.x DC, that we should create "stub"
> extensions for the removed stuff that only carry and validate
> configuration but aren't actually supported on 8.x servers.  This seems
> like a valid possibility to me.
> --
> - DML
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing JAXR & backward compatiblity

Brian Stansberry
Thanks Thomas, for raising this and for the JIRA.

I've outlined what I think is needed for the stub extensions as a
comment on https://issues.jboss.org/browse/AS7-6656 .

Can I request that folks hold up on deleting these subsystems? I think
it will be easier to make these changes and then delete the unneeded
runtime stuff than it will be to semi-restore from history and then change.

The ones that have already been deleted, it's no big deal.

On 2/28/13 10:35 AM, Thomas Diesler wrote:

> Ok, stub extensions is the obvious alternative to breaking compatibility. I'll leave this as a future task and create a jira for it if that's ok with you.
>
> cheers
> --thomas
>
> On Feb 28, 2013, at 4:22 PM, David M. Lloyd <[hidden email]> wrote:
>
>> On 02/28/2013 05:57 AM, Thomas Diesler wrote:
>>> Folks,
>>>
>>> related to
>>>
>>> * [AS7-6612 <https://issues.jboss.org/browse/AS7-6612>] Remove JAXR support
>>>
>>> I'd like to know whether we need to preserve backward compatibility of
>>> the configuration and if so what should happen if there is a jaxr config
>>> item? Generally, can AS8 break backward compatibility with respect to
>>> the config?
>>
>> Brian points out that we don't have a specific requirement to maintain
>> compatibility with obsolete subsystems.  I think we could go ahead with
>> the removal (granted part of the reason I feel this way is that I've
>> already removed JSR-88...).
>>
>> Going forward though Kabir suggested that if we do want to, say, allow
>> 7.x instances to be managed from an 8.x DC, that we should create "stub"
>> extensions for the removed stuff that only carry and validate
>> configuration but aren't actually supported on 8.x servers.  This seems
>> like a valid possibility to me.
>> --
>> - DML
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Thomas Diesler
> JBoss OSGi Lead
> JBoss, a division of Red Hat
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing JAXR & backward compatiblity

David Lloyd-2
I wonder - should we retain a skeletal version of each of these modules?
  I was thinking maybe it would be better to maintain one big
"removed-subsystems" or "compat-subsystems" module or something like
that where we can neatly/consistently organize all the model stuff for
these removals.

On 03/01/2013 09:39 AM, Brian Stansberry wrote:

> Thanks Thomas, for raising this and for the JIRA.
>
> I've outlined what I think is needed for the stub extensions as a
> comment on https://issues.jboss.org/browse/AS7-6656 .
>
> Can I request that folks hold up on deleting these subsystems? I think
> it will be easier to make these changes and then delete the unneeded
> runtime stuff than it will be to semi-restore from history and then change.
>
> The ones that have already been deleted, it's no big deal.
>
> On 2/28/13 10:35 AM, Thomas Diesler wrote:
>> Ok, stub extensions is the obvious alternative to breaking compatibility. I'll leave this as a future task and create a jira for it if that's ok with you.
>>
>> cheers
>> --thomas
>>
>> On Feb 28, 2013, at 4:22 PM, David M. Lloyd <[hidden email]> wrote:
>>
>>> On 02/28/2013 05:57 AM, Thomas Diesler wrote:
>>>> Folks,
>>>>
>>>> related to
>>>>
>>>> * [AS7-6612 <https://issues.jboss.org/browse/AS7-6612>] Remove JAXR support
>>>>
>>>> I'd like to know whether we need to preserve backward compatibility of
>>>> the configuration and if so what should happen if there is a jaxr config
>>>> item? Generally, can AS8 break backward compatibility with respect to
>>>> the config?
>>>
>>> Brian points out that we don't have a specific requirement to maintain
>>> compatibility with obsolete subsystems.  I think we could go ahead with
>>> the removal (granted part of the reason I feel this way is that I've
>>> already removed JSR-88...).
>>>
>>> Going forward though Kabir suggested that if we do want to, say, allow
>>> 7.x instances to be managed from an 8.x DC, that we should create "stub"
>>> extensions for the removed stuff that only carry and validate
>>> configuration but aren't actually supported on 8.x servers.  This seems
>>> like a valid possibility to me.
>>> --
>>> - DML
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> Thomas Diesler
>> JBoss OSGi Lead
>> JBoss, a division of Red Hat
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>
>


--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing JAXR & backward compatiblity

Brian Stansberry
In terms of code organization, perhaps. But the way the extension is
activated in the HCs and servers is via the module name. So if you want
a 7.2 server to be able to run CMP, there is going to have to be a
module named org.jboss.as.cmp.

On 3/1/13 2:13 PM, David M. Lloyd wrote:

> I wonder - should we retain a skeletal version of each of these modules?
>    I was thinking maybe it would be better to maintain one big
> "removed-subsystems" or "compat-subsystems" module or something like
> that where we can neatly/consistently organize all the model stuff for
> these removals.
>
> On 03/01/2013 09:39 AM, Brian Stansberry wrote:
>> Thanks Thomas, for raising this and for the JIRA.
>>
>> I've outlined what I think is needed for the stub extensions as a
>> comment on https://issues.jboss.org/browse/AS7-6656 .
>>
>> Can I request that folks hold up on deleting these subsystems? I think
>> it will be easier to make these changes and then delete the unneeded
>> runtime stuff than it will be to semi-restore from history and then change.
>>
>> The ones that have already been deleted, it's no big deal.
>>
>> On 2/28/13 10:35 AM, Thomas Diesler wrote:
>>> Ok, stub extensions is the obvious alternative to breaking compatibility. I'll leave this as a future task and create a jira for it if that's ok with you.
>>>
>>> cheers
>>> --thomas
>>>
>>> On Feb 28, 2013, at 4:22 PM, David M. Lloyd <[hidden email]> wrote:
>>>
>>>> On 02/28/2013 05:57 AM, Thomas Diesler wrote:
>>>>> Folks,
>>>>>
>>>>> related to
>>>>>
>>>>> * [AS7-6612 <https://issues.jboss.org/browse/AS7-6612>] Remove JAXR support
>>>>>
>>>>> I'd like to know whether we need to preserve backward compatibility of
>>>>> the configuration and if so what should happen if there is a jaxr config
>>>>> item? Generally, can AS8 break backward compatibility with respect to
>>>>> the config?
>>>>
>>>> Brian points out that we don't have a specific requirement to maintain
>>>> compatibility with obsolete subsystems.  I think we could go ahead with
>>>> the removal (granted part of the reason I feel this way is that I've
>>>> already removed JSR-88...).
>>>>
>>>> Going forward though Kabir suggested that if we do want to, say, allow
>>>> 7.x instances to be managed from an 8.x DC, that we should create "stub"
>>>> extensions for the removed stuff that only carry and validate
>>>> configuration but aren't actually supported on 8.x servers.  This seems
>>>> like a valid possibility to me.
>>>> --
>>>> - DML
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>> Thomas Diesler
>>> JBoss OSGi Lead
>>> JBoss, a division of Red Hat
>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>
>>
>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing JAXR & backward compatiblity

David Lloyd-2
Yeah, I was thinking they could just be aliases or stubs though.

On 03/01/2013 02:22 PM, Brian Stansberry wrote:

> In terms of code organization, perhaps. But the way the extension is
> activated in the HCs and servers is via the module name. So if you want
> a 7.2 server to be able to run CMP, there is going to have to be a
> module named org.jboss.as.cmp.
>
> On 3/1/13 2:13 PM, David M. Lloyd wrote:
>> I wonder - should we retain a skeletal version of each of these modules?
>>     I was thinking maybe it would be better to maintain one big
>> "removed-subsystems" or "compat-subsystems" module or something like
>> that where we can neatly/consistently organize all the model stuff for
>> these removals.
>>
>> On 03/01/2013 09:39 AM, Brian Stansberry wrote:
>>> Thanks Thomas, for raising this and for the JIRA.
>>>
>>> I've outlined what I think is needed for the stub extensions as a
>>> comment on https://issues.jboss.org/browse/AS7-6656 .
>>>
>>> Can I request that folks hold up on deleting these subsystems? I think
>>> it will be easier to make these changes and then delete the unneeded
>>> runtime stuff than it will be to semi-restore from history and then change.
>>>
>>> The ones that have already been deleted, it's no big deal.
>>>
>>> On 2/28/13 10:35 AM, Thomas Diesler wrote:
>>>> Ok, stub extensions is the obvious alternative to breaking compatibility. I'll leave this as a future task and create a jira for it if that's ok with you.
>>>>
>>>> cheers
>>>> --thomas
>>>>
>>>> On Feb 28, 2013, at 4:22 PM, David M. Lloyd <[hidden email]> wrote:
>>>>
>>>>> On 02/28/2013 05:57 AM, Thomas Diesler wrote:
>>>>>> Folks,
>>>>>>
>>>>>> related to
>>>>>>
>>>>>> * [AS7-6612 <https://issues.jboss.org/browse/AS7-6612>] Remove JAXR support
>>>>>>
>>>>>> I'd like to know whether we need to preserve backward compatibility of
>>>>>> the configuration and if so what should happen if there is a jaxr config
>>>>>> item? Generally, can AS8 break backward compatibility with respect to
>>>>>> the config?
>>>>>
>>>>> Brian points out that we don't have a specific requirement to maintain
>>>>> compatibility with obsolete subsystems.  I think we could go ahead with
>>>>> the removal (granted part of the reason I feel this way is that I've
>>>>> already removed JSR-88...).
>>>>>
>>>>> Going forward though Kabir suggested that if we do want to, say, allow
>>>>> 7.x instances to be managed from an 8.x DC, that we should create "stub"
>>>>> extensions for the removed stuff that only carry and validate
>>>>> configuration but aren't actually supported on 8.x servers.  This seems
>>>>> like a valid possibility to me.
>>>>> --
>>>>> - DML
>>>>> _______________________________________________
>>>>> jboss-as7-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>> Thomas Diesler
>>>> JBoss OSGi Lead
>>>> JBoss, a division of Red Hat
>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>>
>>>
>>
>>
>
>


--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing JAXR & backward compatiblity

Brian Stansberry
I'm not sure how the ServiceLoader part would work there. At least not
with what I imagine when I think of an "alias." With some kind of stub
where each has a different
META-INF/services/org.jboss.as.controller.Extension file it could work.

On 3/1/13 2:29 PM, David M. Lloyd wrote:

> Yeah, I was thinking they could just be aliases or stubs though.
>
> On 03/01/2013 02:22 PM, Brian Stansberry wrote:
>> In terms of code organization, perhaps. But the way the extension is
>> activated in the HCs and servers is via the module name. So if you want
>> a 7.2 server to be able to run CMP, there is going to have to be a
>> module named org.jboss.as.cmp.
>>
>> On 3/1/13 2:13 PM, David M. Lloyd wrote:
>>> I wonder - should we retain a skeletal version of each of these modules?
>>>      I was thinking maybe it would be better to maintain one big
>>> "removed-subsystems" or "compat-subsystems" module or something like
>>> that where we can neatly/consistently organize all the model stuff for
>>> these removals.
>>>
>>> On 03/01/2013 09:39 AM, Brian Stansberry wrote:
>>>> Thanks Thomas, for raising this and for the JIRA.
>>>>
>>>> I've outlined what I think is needed for the stub extensions as a
>>>> comment on https://issues.jboss.org/browse/AS7-6656 .
>>>>
>>>> Can I request that folks hold up on deleting these subsystems? I think
>>>> it will be easier to make these changes and then delete the unneeded
>>>> runtime stuff than it will be to semi-restore from history and then change.
>>>>
>>>> The ones that have already been deleted, it's no big deal.
>>>>
>>>> On 2/28/13 10:35 AM, Thomas Diesler wrote:
>>>>> Ok, stub extensions is the obvious alternative to breaking compatibility. I'll leave this as a future task and create a jira for it if that's ok with you.
>>>>>
>>>>> cheers
>>>>> --thomas
>>>>>
>>>>> On Feb 28, 2013, at 4:22 PM, David M. Lloyd <[hidden email]> wrote:
>>>>>
>>>>>> On 02/28/2013 05:57 AM, Thomas Diesler wrote:
>>>>>>> Folks,
>>>>>>>
>>>>>>> related to
>>>>>>>
>>>>>>> * [AS7-6612 <https://issues.jboss.org/browse/AS7-6612>] Remove JAXR support
>>>>>>>
>>>>>>> I'd like to know whether we need to preserve backward compatibility of
>>>>>>> the configuration and if so what should happen if there is a jaxr config
>>>>>>> item? Generally, can AS8 break backward compatibility with respect to
>>>>>>> the config?
>>>>>>
>>>>>> Brian points out that we don't have a specific requirement to maintain
>>>>>> compatibility with obsolete subsystems.  I think we could go ahead with
>>>>>> the removal (granted part of the reason I feel this way is that I've
>>>>>> already removed JSR-88...).
>>>>>>
>>>>>> Going forward though Kabir suggested that if we do want to, say, allow
>>>>>> 7.x instances to be managed from an 8.x DC, that we should create "stub"
>>>>>> extensions for the removed stuff that only carry and validate
>>>>>> configuration but aren't actually supported on 8.x servers.  This seems
>>>>>> like a valid possibility to me.
>>>>>> --
>>>>>> - DML
>>>>>> _______________________________________________
>>>>>> jboss-as7-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>
>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>> Thomas Diesler
>>>>> JBoss OSGi Lead
>>>>> JBoss, a division of Red Hat
>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jboss-as7-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing JAXR & backward compatiblity

Tomaž Cerar-2
We could just have special handling for loading this legacy sub extensions.
Given that they matter only for domain controller and not for everything else it could be done.

How domain controller loads this stub stuff, should not matter to 7.2 HC,
as long it as comes in format that it can digest.



On Fri, Mar 1, 2013 at 9:48 PM, Brian Stansberry <[hidden email]> wrote:
I'm not sure how the ServiceLoader part would work there. At least not
with what I imagine when I think of an "alias." With some kind of stub
where each has a different
META-INF/services/org.jboss.as.controller.Extension file it could work.

On 3/1/13 2:29 PM, David M. Lloyd wrote:
> Yeah, I was thinking they could just be aliases or stubs though.
>
> On 03/01/2013 02:22 PM, Brian Stansberry wrote:
>> In terms of code organization, perhaps. But the way the extension is
>> activated in the HCs and servers is via the module name. So if you want
>> a 7.2 server to be able to run CMP, there is going to have to be a
>> module named org.jboss.as.cmp.
>>
>> On 3/1/13 2:13 PM, David M. Lloyd wrote:
>>> I wonder - should we retain a skeletal version of each of these modules?
>>>      I was thinking maybe it would be better to maintain one big
>>> "removed-subsystems" or "compat-subsystems" module or something like
>>> that where we can neatly/consistently organize all the model stuff for
>>> these removals.
>>>
>>> On 03/01/2013 09:39 AM, Brian Stansberry wrote:
>>>> Thanks Thomas, for raising this and for the JIRA.
>>>>
>>>> I've outlined what I think is needed for the stub extensions as a
>>>> comment on https://issues.jboss.org/browse/AS7-6656 .
>>>>
>>>> Can I request that folks hold up on deleting these subsystems? I think
>>>> it will be easier to make these changes and then delete the unneeded
>>>> runtime stuff than it will be to semi-restore from history and then change.
>>>>
>>>> The ones that have already been deleted, it's no big deal.
>>>>
>>>> On 2/28/13 10:35 AM, Thomas Diesler wrote:
>>>>> Ok, stub extensions is the obvious alternative to breaking compatibility. I'll leave this as a future task and create a jira for it if that's ok with you.
>>>>>
>>>>> cheers
>>>>> --thomas
>>>>>
>>>>> On Feb 28, 2013, at 4:22 PM, David M. Lloyd <[hidden email]> wrote:
>>>>>
>>>>>> On 02/28/2013 05:57 AM, Thomas Diesler wrote:
>>>>>>> Folks,
>>>>>>>
>>>>>>> related to
>>>>>>>
>>>>>>> * [AS7-6612 <https://issues.jboss.org/browse/AS7-6612>] Remove JAXR support
>>>>>>>
>>>>>>> I'd like to know whether we need to preserve backward compatibility of
>>>>>>> the configuration and if so what should happen if there is a jaxr config
>>>>>>> item? Generally, can AS8 break backward compatibility with respect to
>>>>>>> the config?
>>>>>>
>>>>>> Brian points out that we don't have a specific requirement to maintain
>>>>>> compatibility with obsolete subsystems.  I think we could go ahead with
>>>>>> the removal (granted part of the reason I feel this way is that I've
>>>>>> already removed JSR-88...).
>>>>>>
>>>>>> Going forward though Kabir suggested that if we do want to, say, allow
>>>>>> 7.x instances to be managed from an 8.x DC, that we should create "stub"
>>>>>> extensions for the removed stuff that only carry and validate
>>>>>> configuration but aren't actually supported on 8.x servers.  This seems
>>>>>> like a valid possibility to me.
>>>>>> --
>>>>>> - DML
>>>>>> _______________________________________________
>>>>>> jboss-as7-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>
>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>> Thomas Diesler
>>>>> JBoss OSGi Lead
>>>>> JBoss, a division of Red Hat
>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jboss-as7-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing JAXR & backward compatiblity

Brian Stansberry
I feel like something pretty simple is becoming complicated. :)

On 3/1/13 3:05 PM, Tomaž Cerar wrote:

> We could just have special handling for loading this legacy sub extensions.
> Given that they matter only for domain controller and not for everything
> else it could be done.
>
> How domain controller loads this stub stuff, should not matter to 7.2 HC,
> as long it as comes in format that it can digest.
>
>
>
> On Fri, Mar 1, 2013 at 9:48 PM, Brian Stansberry
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     I'm not sure how the ServiceLoader part would work there. At least not
>     with what I imagine when I think of an "alias." With some kind of stub
>     where each has a different
>     META-INF/services/org.jboss.as.controller.Extension file it could work.
>
>     On 3/1/13 2:29 PM, David M. Lloyd wrote:
>      > Yeah, I was thinking they could just be aliases or stubs though.
>      >
>      > On 03/01/2013 02:22 PM, Brian Stansberry wrote:
>      >> In terms of code organization, perhaps. But the way the extension is
>      >> activated in the HCs and servers is via the module name. So if
>     you want
>      >> a 7.2 server to be able to run CMP, there is going to have to be a
>      >> module named org.jboss.as.cmp.
>      >>
>      >> On 3/1/13 2:13 PM, David M. Lloyd wrote:
>      >>> I wonder - should we retain a skeletal version of each of these
>     modules?
>      >>>      I was thinking maybe it would be better to maintain one big
>      >>> "removed-subsystems" or "compat-subsystems" module or something
>     like
>      >>> that where we can neatly/consistently organize all the model
>     stuff for
>      >>> these removals.
>      >>>
>      >>> On 03/01/2013 09:39 AM, Brian Stansberry wrote:
>      >>>> Thanks Thomas, for raising this and for the JIRA.
>      >>>>
>      >>>> I've outlined what I think is needed for the stub extensions as a
>      >>>> comment on https://issues.jboss.org/browse/AS7-6656 .
>      >>>>
>      >>>> Can I request that folks hold up on deleting these subsystems?
>     I think
>      >>>> it will be easier to make these changes and then delete the
>     unneeded
>      >>>> runtime stuff than it will be to semi-restore from history and
>     then change.
>      >>>>
>      >>>> The ones that have already been deleted, it's no big deal.
>      >>>>
>      >>>> On 2/28/13 10:35 AM, Thomas Diesler wrote:
>      >>>>> Ok, stub extensions is the obvious alternative to breaking
>     compatibility. I'll leave this as a future task and create a jira
>     for it if that's ok with you.
>      >>>>>
>      >>>>> cheers
>      >>>>> --thomas
>      >>>>>
>      >>>>> On Feb 28, 2013, at 4:22 PM, David M. Lloyd
>     <[hidden email] <mailto:[hidden email]>> wrote:
>      >>>>>
>      >>>>>> On 02/28/2013 05:57 AM, Thomas Diesler wrote:
>      >>>>>>> Folks,
>      >>>>>>>
>      >>>>>>> related to
>      >>>>>>>
>      >>>>>>> * [AS7-6612 <https://issues.jboss.org/browse/AS7-6612>]
>     Remove JAXR support
>      >>>>>>>
>      >>>>>>> I'd like to know whether we need to preserve backward
>     compatibility of
>      >>>>>>> the configuration and if so what should happen if there is
>     a jaxr config
>      >>>>>>> item? Generally, can AS8 break backward compatibility with
>     respect to
>      >>>>>>> the config?
>      >>>>>>
>      >>>>>> Brian points out that we don't have a specific requirement
>     to maintain
>      >>>>>> compatibility with obsolete subsystems.  I think we could go
>     ahead with
>      >>>>>> the removal (granted part of the reason I feel this way is
>     that I've
>      >>>>>> already removed JSR-88...).
>      >>>>>>
>      >>>>>> Going forward though Kabir suggested that if we do want to,
>     say, allow
>      >>>>>> 7.x instances to be managed from an 8.x DC, that we should
>     create "stub"
>      >>>>>> extensions for the removed stuff that only carry and validate
>      >>>>>> configuration but aren't actually supported on 8.x servers.
>       This seems
>      >>>>>> like a valid possibility to me.
>      >>>>>> --
>      >>>>>> - DML
>      >>>>>> _______________________________________________
>      >>>>>> jboss-as7-dev mailing list
>      >>>>>> [hidden email]
>     <mailto:[hidden email]>
>      >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>      >>>>>
>      >>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>      >>>>> Thomas Diesler
>      >>>>> JBoss OSGi Lead
>      >>>>> JBoss, a division of Red Hat
>      >>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>      >>>>>
>      >>>>>
>      >>>>>
>      >>>>>
>      >>>>> _______________________________________________
>      >>>>> jboss-as7-dev mailing list
>      >>>>> [hidden email]
>     <mailto:[hidden email]>
>      >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>      >>>>>
>      >>>>
>      >>>>
>      >>>
>      >>>
>      >>
>      >>
>      >
>      >
>
>
>     --
>     Brian Stansberry
>     Principal Software Engineer
>     JBoss by Red Hat
>     _______________________________________________
>     jboss-as7-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing JAXR & backward compatiblity

David Lloyd-2
Maybe, OTOH it's good to think of these things now; I think it'd kinda
suck to end up with like 30 of these things floating around as modules
when we get to AS 10, 11...

On 03/01/2013 03:19 PM, Brian Stansberry wrote:

> I feel like something pretty simple is becoming complicated. :)
>
> On 3/1/13 3:05 PM, Tomaž Cerar wrote:
>> We could just have special handling for loading this legacy sub extensions.
>> Given that they matter only for domain controller and not for everything
>> else it could be done.
>>
>> How domain controller loads this stub stuff, should not matter to 7.2 HC,
>> as long it as comes in format that it can digest.
>>
>>
>>
>> On Fri, Mar 1, 2013 at 9:48 PM, Brian Stansberry
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>      I'm not sure how the ServiceLoader part would work there. At least not
>>      with what I imagine when I think of an "alias." With some kind of stub
>>      where each has a different
>>      META-INF/services/org.jboss.as.controller.Extension file it could work.
>>
>>      On 3/1/13 2:29 PM, David M. Lloyd wrote:
>>       > Yeah, I was thinking they could just be aliases or stubs though.
>>       >
>>       > On 03/01/2013 02:22 PM, Brian Stansberry wrote:
>>       >> In terms of code organization, perhaps. But the way the extension is
>>       >> activated in the HCs and servers is via the module name. So if
>>      you want
>>       >> a 7.2 server to be able to run CMP, there is going to have to be a
>>       >> module named org.jboss.as.cmp.
>>       >>
>>       >> On 3/1/13 2:13 PM, David M. Lloyd wrote:
>>       >>> I wonder - should we retain a skeletal version of each of these
>>      modules?
>>       >>>      I was thinking maybe it would be better to maintain one big
>>       >>> "removed-subsystems" or "compat-subsystems" module or something
>>      like
>>       >>> that where we can neatly/consistently organize all the model
>>      stuff for
>>       >>> these removals.
>>       >>>
>>       >>> On 03/01/2013 09:39 AM, Brian Stansberry wrote:
>>       >>>> Thanks Thomas, for raising this and for the JIRA.
>>       >>>>
>>       >>>> I've outlined what I think is needed for the stub extensions as a
>>       >>>> comment on https://issues.jboss.org/browse/AS7-6656 .
>>       >>>>
>>       >>>> Can I request that folks hold up on deleting these subsystems?
>>      I think
>>       >>>> it will be easier to make these changes and then delete the
>>      unneeded
>>       >>>> runtime stuff than it will be to semi-restore from history and
>>      then change.
>>       >>>>
>>       >>>> The ones that have already been deleted, it's no big deal.
>>       >>>>
>>       >>>> On 2/28/13 10:35 AM, Thomas Diesler wrote:
>>       >>>>> Ok, stub extensions is the obvious alternative to breaking
>>      compatibility. I'll leave this as a future task and create a jira
>>      for it if that's ok with you.
>>       >>>>>
>>       >>>>> cheers
>>       >>>>> --thomas
>>       >>>>>
>>       >>>>> On Feb 28, 2013, at 4:22 PM, David M. Lloyd
>>      <[hidden email] <mailto:[hidden email]>> wrote:
>>       >>>>>
>>       >>>>>> On 02/28/2013 05:57 AM, Thomas Diesler wrote:
>>       >>>>>>> Folks,
>>       >>>>>>>
>>       >>>>>>> related to
>>       >>>>>>>
>>       >>>>>>> * [AS7-6612 <https://issues.jboss.org/browse/AS7-6612>]
>>      Remove JAXR support
>>       >>>>>>>
>>       >>>>>>> I'd like to know whether we need to preserve backward
>>      compatibility of
>>       >>>>>>> the configuration and if so what should happen if there is
>>      a jaxr config
>>       >>>>>>> item? Generally, can AS8 break backward compatibility with
>>      respect to
>>       >>>>>>> the config?
>>       >>>>>>
>>       >>>>>> Brian points out that we don't have a specific requirement
>>      to maintain
>>       >>>>>> compatibility with obsolete subsystems.  I think we could go
>>      ahead with
>>       >>>>>> the removal (granted part of the reason I feel this way is
>>      that I've
>>       >>>>>> already removed JSR-88...).
>>       >>>>>>
>>       >>>>>> Going forward though Kabir suggested that if we do want to,
>>      say, allow
>>       >>>>>> 7.x instances to be managed from an 8.x DC, that we should
>>      create "stub"
>>       >>>>>> extensions for the removed stuff that only carry and validate
>>       >>>>>> configuration but aren't actually supported on 8.x servers.
>>        This seems
>>       >>>>>> like a valid possibility to me.
>>       >>>>>> --
>>       >>>>>> - DML
>>       >>>>>> _______________________________________________
>>       >>>>>> jboss-as7-dev mailing list
>>       >>>>>> [hidden email]
>>      <mailto:[hidden email]>
>>       >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>       >>>>>
>>       >>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>       >>>>> Thomas Diesler
>>       >>>>> JBoss OSGi Lead
>>       >>>>> JBoss, a division of Red Hat
>>       >>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>       >>>>>
>>       >>>>>
>>       >>>>>
>>       >>>>>
>>       >>>>> _______________________________________________
>>       >>>>> jboss-as7-dev mailing list
>>       >>>>> [hidden email]
>>      <mailto:[hidden email]>
>>       >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>       >>>>>
>>       >>>>
>>       >>>>
>>       >>>
>>       >>>
>>       >>
>>       >>
>>       >
>>       >
>>
>>
>>      --
>>      Brian Stansberry
>>      Principal Software Engineer
>>      JBoss by Red Hat
>>      _______________________________________________
>>      jboss-as7-dev mailing list
>>      [hidden email] <mailto:[hidden email]>
>>      https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>
>


--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing JAXR & backward compatiblity

Brian Stansberry
OK, if anyone has a suggestion, please write down all the details of how
some other construct can be handled on the master HC and then propagated
to the legacy slaves.

Please clarify in the proposal whether it requires all legacy modules to
be present on the target slave, or whether the user retains the option
of pruning undesired modules.

On 3/1/13 3:25 PM, David M. Lloyd wrote:

> Maybe, OTOH it's good to think of these things now; I think it'd kinda
> suck to end up with like 30 of these things floating around as modules
> when we get to AS 10, 11...
>
> On 03/01/2013 03:19 PM, Brian Stansberry wrote:
>> I feel like something pretty simple is becoming complicated. :)
>>
>> On 3/1/13 3:05 PM, Tomaž Cerar wrote:
>>> We could just have special handling for loading this legacy sub extensions.
>>> Given that they matter only for domain controller and not for everything
>>> else it could be done.
>>>
>>> How domain controller loads this stub stuff, should not matter to 7.2 HC,
>>> as long it as comes in format that it can digest.
>>>
>>>
>>>
>>> On Fri, Mar 1, 2013 at 9:48 PM, Brian Stansberry
>>> <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>>       I'm not sure how the ServiceLoader part would work there. At least not
>>>       with what I imagine when I think of an "alias." With some kind of stub
>>>       where each has a different
>>>       META-INF/services/org.jboss.as.controller.Extension file it could work.
>>>
>>>       On 3/1/13 2:29 PM, David M. Lloyd wrote:
>>>        > Yeah, I was thinking they could just be aliases or stubs though.
>>>        >
>>>        > On 03/01/2013 02:22 PM, Brian Stansberry wrote:
>>>        >> In terms of code organization, perhaps. But the way the extension is
>>>        >> activated in the HCs and servers is via the module name. So if
>>>       you want
>>>        >> a 7.2 server to be able to run CMP, there is going to have to be a
>>>        >> module named org.jboss.as.cmp.
>>>        >>
>>>        >> On 3/1/13 2:13 PM, David M. Lloyd wrote:
>>>        >>> I wonder - should we retain a skeletal version of each of these
>>>       modules?
>>>        >>>      I was thinking maybe it would be better to maintain one big
>>>        >>> "removed-subsystems" or "compat-subsystems" module or something
>>>       like
>>>        >>> that where we can neatly/consistently organize all the model
>>>       stuff for
>>>        >>> these removals.
>>>        >>>
>>>        >>> On 03/01/2013 09:39 AM, Brian Stansberry wrote:
>>>        >>>> Thanks Thomas, for raising this and for the JIRA.
>>>        >>>>
>>>        >>>> I've outlined what I think is needed for the stub extensions as a
>>>        >>>> comment on https://issues.jboss.org/browse/AS7-6656 .
>>>        >>>>
>>>        >>>> Can I request that folks hold up on deleting these subsystems?
>>>       I think
>>>        >>>> it will be easier to make these changes and then delete the
>>>       unneeded
>>>        >>>> runtime stuff than it will be to semi-restore from history and
>>>       then change.
>>>        >>>>
>>>        >>>> The ones that have already been deleted, it's no big deal.
>>>        >>>>
>>>        >>>> On 2/28/13 10:35 AM, Thomas Diesler wrote:
>>>        >>>>> Ok, stub extensions is the obvious alternative to breaking
>>>       compatibility. I'll leave this as a future task and create a jira
>>>       for it if that's ok with you.
>>>        >>>>>
>>>        >>>>> cheers
>>>        >>>>> --thomas
>>>        >>>>>
>>>        >>>>> On Feb 28, 2013, at 4:22 PM, David M. Lloyd
>>>       <[hidden email] <mailto:[hidden email]>> wrote:
>>>        >>>>>
>>>        >>>>>> On 02/28/2013 05:57 AM, Thomas Diesler wrote:
>>>        >>>>>>> Folks,
>>>        >>>>>>>
>>>        >>>>>>> related to
>>>        >>>>>>>
>>>        >>>>>>> * [AS7-6612 <https://issues.jboss.org/browse/AS7-6612>]
>>>       Remove JAXR support
>>>        >>>>>>>
>>>        >>>>>>> I'd like to know whether we need to preserve backward
>>>       compatibility of
>>>        >>>>>>> the configuration and if so what should happen if there is
>>>       a jaxr config
>>>        >>>>>>> item? Generally, can AS8 break backward compatibility with
>>>       respect to
>>>        >>>>>>> the config?
>>>        >>>>>>
>>>        >>>>>> Brian points out that we don't have a specific requirement
>>>       to maintain
>>>        >>>>>> compatibility with obsolete subsystems.  I think we could go
>>>       ahead with
>>>        >>>>>> the removal (granted part of the reason I feel this way is
>>>       that I've
>>>        >>>>>> already removed JSR-88...).
>>>        >>>>>>
>>>        >>>>>> Going forward though Kabir suggested that if we do want to,
>>>       say, allow
>>>        >>>>>> 7.x instances to be managed from an 8.x DC, that we should
>>>       create "stub"
>>>        >>>>>> extensions for the removed stuff that only carry and validate
>>>        >>>>>> configuration but aren't actually supported on 8.x servers.
>>>         This seems
>>>        >>>>>> like a valid possibility to me.
>>>        >>>>>> --
>>>        >>>>>> - DML
>>>        >>>>>> _______________________________________________
>>>        >>>>>> jboss-as7-dev mailing list
>>>        >>>>>> [hidden email]
>>>       <mailto:[hidden email]>
>>>        >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>        >>>>>
>>>        >>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>        >>>>> Thomas Diesler
>>>        >>>>> JBoss OSGi Lead
>>>        >>>>> JBoss, a division of Red Hat
>>>        >>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>        >>>>>
>>>        >>>>>
>>>        >>>>>
>>>        >>>>>
>>>        >>>>> _______________________________________________
>>>        >>>>> jboss-as7-dev mailing list
>>>        >>>>> [hidden email]
>>>       <mailto:[hidden email]>
>>>        >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>        >>>>>
>>>        >>>>
>>>        >>>>
>>>        >>>
>>>        >>>
>>>        >>
>>>        >>
>>>        >
>>>        >
>>>
>>>
>>>       --
>>>       Brian Stansberry
>>>       Principal Software Engineer
>>>       JBoss by Red Hat
>>>       _______________________________________________
>>>       jboss-as7-dev mailing list
>>>       [hidden email] <mailto:[hidden email]>
>>>       https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>>
>>
>>
>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing JAXR & backward compatiblity

David Lloyd-2
In reply to this post by Brian Stansberry
Rewinding the discussion a bit :)

If we just had one compat module (with N pure aliases), it could easily
register all the subsystems for all the modules at that time (subsystem
registration is pretty lightweight these days, or so it seems at a
glance).  If extra subsystems are available as a result of an extension
reg I don't see that as harmless.

On 03/01/2013 02:48 PM, Brian Stansberry wrote:

> I'm not sure how the ServiceLoader part would work there. At least not
> with what I imagine when I think of an "alias." With some kind of stub
> where each has a different
> META-INF/services/org.jboss.as.controller.Extension file it could work.
>
> On 3/1/13 2:29 PM, David M. Lloyd wrote:
>> Yeah, I was thinking they could just be aliases or stubs though.
>>
>> On 03/01/2013 02:22 PM, Brian Stansberry wrote:
>>> In terms of code organization, perhaps. But the way the extension is
>>> activated in the HCs and servers is via the module name. So if you want
>>> a 7.2 server to be able to run CMP, there is going to have to be a
>>> module named org.jboss.as.cmp.
>>>
>>> On 3/1/13 2:13 PM, David M. Lloyd wrote:
>>>> I wonder - should we retain a skeletal version of each of these modules?
>>>>       I was thinking maybe it would be better to maintain one big
>>>> "removed-subsystems" or "compat-subsystems" module or something like
>>>> that where we can neatly/consistently organize all the model stuff for
>>>> these removals.
>>>>
>>>> On 03/01/2013 09:39 AM, Brian Stansberry wrote:
>>>>> Thanks Thomas, for raising this and for the JIRA.
>>>>>
>>>>> I've outlined what I think is needed for the stub extensions as a
>>>>> comment on https://issues.jboss.org/browse/AS7-6656 .
>>>>>
>>>>> Can I request that folks hold up on deleting these subsystems? I think
>>>>> it will be easier to make these changes and then delete the unneeded
>>>>> runtime stuff than it will be to semi-restore from history and then change.
>>>>>
>>>>> The ones that have already been deleted, it's no big deal.
>>>>>
>>>>> On 2/28/13 10:35 AM, Thomas Diesler wrote:
>>>>>> Ok, stub extensions is the obvious alternative to breaking compatibility. I'll leave this as a future task and create a jira for it if that's ok with you.
>>>>>>
>>>>>> cheers
>>>>>> --thomas
>>>>>>
>>>>>> On Feb 28, 2013, at 4:22 PM, David M. Lloyd <[hidden email]> wrote:
>>>>>>
>>>>>>> On 02/28/2013 05:57 AM, Thomas Diesler wrote:
>>>>>>>> Folks,
>>>>>>>>
>>>>>>>> related to
>>>>>>>>
>>>>>>>> * [AS7-6612 <https://issues.jboss.org/browse/AS7-6612>] Remove JAXR support
>>>>>>>>
>>>>>>>> I'd like to know whether we need to preserve backward compatibility of
>>>>>>>> the configuration and if so what should happen if there is a jaxr config
>>>>>>>> item? Generally, can AS8 break backward compatibility with respect to
>>>>>>>> the config?
>>>>>>>
>>>>>>> Brian points out that we don't have a specific requirement to maintain
>>>>>>> compatibility with obsolete subsystems.  I think we could go ahead with
>>>>>>> the removal (granted part of the reason I feel this way is that I've
>>>>>>> already removed JSR-88...).
>>>>>>>
>>>>>>> Going forward though Kabir suggested that if we do want to, say, allow
>>>>>>> 7.x instances to be managed from an 8.x DC, that we should create "stub"
>>>>>>> extensions for the removed stuff that only carry and validate
>>>>>>> configuration but aren't actually supported on 8.x servers.  This seems
>>>>>>> like a valid possibility to me.
>>>>>>> --
>>>>>>> - DML
>>>>>>> _______________________________________________
>>>>>>> jboss-as7-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>
>>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>>> Thomas Diesler
>>>>>> JBoss OSGi Lead
>>>>>> JBoss, a division of Red Hat
>>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> jboss-as7-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing JAXR & backward compatiblity

Brian Stansberry
The extension registration logic would have to be altered to not barf
when multiple aliases all try to register the same extensions/ subsystems.

But it probably should still barf if a user tried to do that for some
other reason. So which is happening needs to be clarified.

A way to do that is to use something other than
org.jboss.as.controller.Extension for the ServiceLoader (i.e. first try
ServiceLoader for "LegacyExtension" and then if not there try for
org.jboss.as.controller.Extension.) That's hacky though unless there is
a real difference in the service API between Extension and what these
legacy extensions do. AFAICT though, there is no API difference;
difference is only in impl.

On 3/1/13 4:23 PM, David M. Lloyd wrote:

> Rewinding the discussion a bit :)
>
> If we just had one compat module (with N pure aliases), it could easily
> register all the subsystems for all the modules at that time (subsystem
> registration is pretty lightweight these days, or so it seems at a
> glance).  If extra subsystems are available as a result of an extension
> reg I don't see that as harmless.
>
> On 03/01/2013 02:48 PM, Brian Stansberry wrote:
>> I'm not sure how the ServiceLoader part would work there. At least not
>> with what I imagine when I think of an "alias." With some kind of stub
>> where each has a different
>> META-INF/services/org.jboss.as.controller.Extension file it could work.
>>
>> On 3/1/13 2:29 PM, David M. Lloyd wrote:
>>> Yeah, I was thinking they could just be aliases or stubs though.
>>>
>>> On 03/01/2013 02:22 PM, Brian Stansberry wrote:
>>>> In terms of code organization, perhaps. But the way the extension is
>>>> activated in the HCs and servers is via the module name. So if you want
>>>> a 7.2 server to be able to run CMP, there is going to have to be a
>>>> module named org.jboss.as.cmp.
>>>>
>>>> On 3/1/13 2:13 PM, David M. Lloyd wrote:
>>>>> I wonder - should we retain a skeletal version of each of these modules?
>>>>>        I was thinking maybe it would be better to maintain one big
>>>>> "removed-subsystems" or "compat-subsystems" module or something like
>>>>> that where we can neatly/consistently organize all the model stuff for
>>>>> these removals.
>>>>>
>>>>> On 03/01/2013 09:39 AM, Brian Stansberry wrote:
>>>>>> Thanks Thomas, for raising this and for the JIRA.
>>>>>>
>>>>>> I've outlined what I think is needed for the stub extensions as a
>>>>>> comment on https://issues.jboss.org/browse/AS7-6656 .
>>>>>>
>>>>>> Can I request that folks hold up on deleting these subsystems? I think
>>>>>> it will be easier to make these changes and then delete the unneeded
>>>>>> runtime stuff than it will be to semi-restore from history and then change.
>>>>>>
>>>>>> The ones that have already been deleted, it's no big deal.
>>>>>>
>>>>>> On 2/28/13 10:35 AM, Thomas Diesler wrote:
>>>>>>> Ok, stub extensions is the obvious alternative to breaking compatibility. I'll leave this as a future task and create a jira for it if that's ok with you.
>>>>>>>
>>>>>>> cheers
>>>>>>> --thomas
>>>>>>>
>>>>>>> On Feb 28, 2013, at 4:22 PM, David M. Lloyd <[hidden email]> wrote:
>>>>>>>
>>>>>>>> On 02/28/2013 05:57 AM, Thomas Diesler wrote:
>>>>>>>>> Folks,
>>>>>>>>>
>>>>>>>>> related to
>>>>>>>>>
>>>>>>>>> * [AS7-6612 <https://issues.jboss.org/browse/AS7-6612>] Remove JAXR support
>>>>>>>>>
>>>>>>>>> I'd like to know whether we need to preserve backward compatibility of
>>>>>>>>> the configuration and if so what should happen if there is a jaxr config
>>>>>>>>> item? Generally, can AS8 break backward compatibility with respect to
>>>>>>>>> the config?
>>>>>>>>
>>>>>>>> Brian points out that we don't have a specific requirement to maintain
>>>>>>>> compatibility with obsolete subsystems.  I think we could go ahead with
>>>>>>>> the removal (granted part of the reason I feel this way is that I've
>>>>>>>> already removed JSR-88...).
>>>>>>>>
>>>>>>>> Going forward though Kabir suggested that if we do want to, say, allow
>>>>>>>> 7.x instances to be managed from an 8.x DC, that we should create "stub"
>>>>>>>> extensions for the removed stuff that only carry and validate
>>>>>>>> configuration but aren't actually supported on 8.x servers.  This seems
>>>>>>>> like a valid possibility to me.
>>>>>>>> --
>>>>>>>> - DML
>>>>>>>> _______________________________________________
>>>>>>>> jboss-as7-dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>
>>>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>>>> Thomas Diesler
>>>>>>> JBoss OSGi Lead
>>>>>>> JBoss, a division of Red Hat
>>>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> jboss-as7-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing JAXR & backward compatiblity

Tomaž Cerar-2
What about if we just use legacy extensions that would be loaded only on DC?
for legacy i mean, why not just have modules / jars from 7.2 in 8.0 distro?
that would make it easiest to support, and no extra work.
We should just put them in some special place in distro,
so it would be obvious that is legacy stuff only DC uses...


On Fri, Mar 1, 2013 at 11:44 PM, Brian Stansberry <[hidden email]> wrote:
The extension registration logic would have to be altered to not barf
when multiple aliases all try to register the same extensions/ subsystems.

But it probably should still barf if a user tried to do that for some
other reason. So which is happening needs to be clarified.

A way to do that is to use something other than
org.jboss.as.controller.Extension for the ServiceLoader (i.e. first try
ServiceLoader for "LegacyExtension" and then if not there try for
org.jboss.as.controller.Extension.) That's hacky though unless there is
a real difference in the service API between Extension and what these
legacy extensions do. AFAICT though, there is no API difference;
difference is only in impl.

On 3/1/13 4:23 PM, David M. Lloyd wrote:
> Rewinding the discussion a bit :)
>
> If we just had one compat module (with N pure aliases), it could easily
> register all the subsystems for all the modules at that time (subsystem
> registration is pretty lightweight these days, or so it seems at a
> glance).  If extra subsystems are available as a result of an extension
> reg I don't see that as harmless.
>
> On 03/01/2013 02:48 PM, Brian Stansberry wrote:
>> I'm not sure how the ServiceLoader part would work there. At least not
>> with what I imagine when I think of an "alias." With some kind of stub
>> where each has a different
>> META-INF/services/org.jboss.as.controller.Extension file it could work.
>>
>> On 3/1/13 2:29 PM, David M. Lloyd wrote:
>>> Yeah, I was thinking they could just be aliases or stubs though.
>>>
>>> On 03/01/2013 02:22 PM, Brian Stansberry wrote:
>>>> In terms of code organization, perhaps. But the way the extension is
>>>> activated in the HCs and servers is via the module name. So if you want
>>>> a 7.2 server to be able to run CMP, there is going to have to be a
>>>> module named org.jboss.as.cmp.
>>>>
>>>> On 3/1/13 2:13 PM, David M. Lloyd wrote:
>>>>> I wonder - should we retain a skeletal version of each of these modules?
>>>>>        I was thinking maybe it would be better to maintain one big
>>>>> "removed-subsystems" or "compat-subsystems" module or something like
>>>>> that where we can neatly/consistently organize all the model stuff for
>>>>> these removals.
>>>>>
>>>>> On 03/01/2013 09:39 AM, Brian Stansberry wrote:
>>>>>> Thanks Thomas, for raising this and for the JIRA.
>>>>>>
>>>>>> I've outlined what I think is needed for the stub extensions as a
>>>>>> comment on https://issues.jboss.org/browse/AS7-6656 .
>>>>>>
>>>>>> Can I request that folks hold up on deleting these subsystems? I think
>>>>>> it will be easier to make these changes and then delete the unneeded
>>>>>> runtime stuff than it will be to semi-restore from history and then change.
>>>>>>
>>>>>> The ones that have already been deleted, it's no big deal.
>>>>>>
>>>>>> On 2/28/13 10:35 AM, Thomas Diesler wrote:
>>>>>>> Ok, stub extensions is the obvious alternative to breaking compatibility. I'll leave this as a future task and create a jira for it if that's ok with you.
>>>>>>>
>>>>>>> cheers
>>>>>>> --thomas
>>>>>>>
>>>>>>> On Feb 28, 2013, at 4:22 PM, David M. Lloyd <[hidden email]> wrote:
>>>>>>>
>>>>>>>> On 02/28/2013 05:57 AM, Thomas Diesler wrote:
>>>>>>>>> Folks,
>>>>>>>>>
>>>>>>>>> related to
>>>>>>>>>
>>>>>>>>> * [AS7-6612 <https://issues.jboss.org/browse/AS7-6612>] Remove JAXR support
>>>>>>>>>
>>>>>>>>> I'd like to know whether we need to preserve backward compatibility of
>>>>>>>>> the configuration and if so what should happen if there is a jaxr config
>>>>>>>>> item? Generally, can AS8 break backward compatibility with respect to
>>>>>>>>> the config?
>>>>>>>>
>>>>>>>> Brian points out that we don't have a specific requirement to maintain
>>>>>>>> compatibility with obsolete subsystems.  I think we could go ahead with
>>>>>>>> the removal (granted part of the reason I feel this way is that I've
>>>>>>>> already removed JSR-88...).
>>>>>>>>
>>>>>>>> Going forward though Kabir suggested that if we do want to, say, allow
>>>>>>>> 7.x instances to be managed from an 8.x DC, that we should create "stub"
>>>>>>>> extensions for the removed stuff that only carry and validate
>>>>>>>> configuration but aren't actually supported on 8.x servers.  This seems
>>>>>>>> like a valid possibility to me.
>>>>>>>> --
>>>>>>>> - DML
>>>>>>>> _______________________________________________
>>>>>>>> jboss-as7-dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>
>>>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>>>> Thomas Diesler
>>>>>>> JBoss OSGi Lead
>>>>>>> JBoss, a division of Red Hat
>>>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> jboss-as7-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing JAXR & backward compatiblity

Brian Stansberry
They have to have logic that prevents their use on an AS8 server. Unless
we are willing to tell folks who use them on AS8 servers and find
problems that they're out of luck and should know better.

On 3/1/13 4:49 PM, Tomaž Cerar wrote:

> What about if we just use legacy extensions that would be loaded only on DC?
> for legacy i mean, why not just have modules / jars from 7.2 in 8.0 distro?
> that would make it easiest to support, and no extra work.
> We should just put them in some special place in distro,
> so it would be obvious that is legacy stuff only DC uses...
>
>
> On Fri, Mar 1, 2013 at 11:44 PM, Brian Stansberry
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     The extension registration logic would have to be altered to not barf
>     when multiple aliases all try to register the same extensions/
>     subsystems.
>
>     But it probably should still barf if a user tried to do that for some
>     other reason. So which is happening needs to be clarified.
>
>     A way to do that is to use something other than
>     org.jboss.as.controller.Extension for the ServiceLoader (i.e. first try
>     ServiceLoader for "LegacyExtension" and then if not there try for
>     org.jboss.as.controller.Extension.) That's hacky though unless there is
>     a real difference in the service API between Extension and what these
>     legacy extensions do. AFAICT though, there is no API difference;
>     difference is only in impl.
>
>     On 3/1/13 4:23 PM, David M. Lloyd wrote:
>      > Rewinding the discussion a bit :)
>      >
>      > If we just had one compat module (with N pure aliases), it could
>     easily
>      > register all the subsystems for all the modules at that time
>     (subsystem
>      > registration is pretty lightweight these days, or so it seems at a
>      > glance).  If extra subsystems are available as a result of an
>     extension
>      > reg I don't see that as harmless.
>      >
>      > On 03/01/2013 02:48 PM, Brian Stansberry wrote:
>      >> I'm not sure how the ServiceLoader part would work there. At
>     least not
>      >> with what I imagine when I think of an "alias." With some kind
>     of stub
>      >> where each has a different
>      >> META-INF/services/org.jboss.as.controller.Extension file it
>     could work.
>      >>
>      >> On 3/1/13 2:29 PM, David M. Lloyd wrote:
>      >>> Yeah, I was thinking they could just be aliases or stubs though.
>      >>>
>      >>> On 03/01/2013 02:22 PM, Brian Stansberry wrote:
>      >>>> In terms of code organization, perhaps. But the way the
>     extension is
>      >>>> activated in the HCs and servers is via the module name. So if
>     you want
>      >>>> a 7.2 server to be able to run CMP, there is going to have to be a
>      >>>> module named org.jboss.as.cmp.
>      >>>>
>      >>>> On 3/1/13 2:13 PM, David M. Lloyd wrote:
>      >>>>> I wonder - should we retain a skeletal version of each of
>     these modules?
>      >>>>>        I was thinking maybe it would be better to maintain
>     one big
>      >>>>> "removed-subsystems" or "compat-subsystems" module or
>     something like
>      >>>>> that where we can neatly/consistently organize all the model
>     stuff for
>      >>>>> these removals.
>      >>>>>
>      >>>>> On 03/01/2013 09:39 AM, Brian Stansberry wrote:
>      >>>>>> Thanks Thomas, for raising this and for the JIRA.
>      >>>>>>
>      >>>>>> I've outlined what I think is needed for the stub extensions
>     as a
>      >>>>>> comment on https://issues.jboss.org/browse/AS7-6656 .
>      >>>>>>
>      >>>>>> Can I request that folks hold up on deleting these
>     subsystems? I think
>      >>>>>> it will be easier to make these changes and then delete the
>     unneeded
>      >>>>>> runtime stuff than it will be to semi-restore from history
>     and then change.
>      >>>>>>
>      >>>>>> The ones that have already been deleted, it's no big deal.
>      >>>>>>
>      >>>>>> On 2/28/13 10:35 AM, Thomas Diesler wrote:
>      >>>>>>> Ok, stub extensions is the obvious alternative to breaking
>     compatibility. I'll leave this as a future task and create a jira
>     for it if that's ok with you.
>      >>>>>>>
>      >>>>>>> cheers
>      >>>>>>> --thomas
>      >>>>>>>
>      >>>>>>> On Feb 28, 2013, at 4:22 PM, David M. Lloyd
>     <[hidden email] <mailto:[hidden email]>> wrote:
>      >>>>>>>
>      >>>>>>>> On 02/28/2013 05:57 AM, Thomas Diesler wrote:
>      >>>>>>>>> Folks,
>      >>>>>>>>>
>      >>>>>>>>> related to
>      >>>>>>>>>
>      >>>>>>>>> * [AS7-6612 <https://issues.jboss.org/browse/AS7-6612>]
>     Remove JAXR support
>      >>>>>>>>>
>      >>>>>>>>> I'd like to know whether we need to preserve backward
>     compatibility of
>      >>>>>>>>> the configuration and if so what should happen if there
>     is a jaxr config
>      >>>>>>>>> item? Generally, can AS8 break backward compatibility
>     with respect to
>      >>>>>>>>> the config?
>      >>>>>>>>
>      >>>>>>>> Brian points out that we don't have a specific requirement
>     to maintain
>      >>>>>>>> compatibility with obsolete subsystems.  I think we could
>     go ahead with
>      >>>>>>>> the removal (granted part of the reason I feel this way is
>     that I've
>      >>>>>>>> already removed JSR-88...).
>      >>>>>>>>
>      >>>>>>>> Going forward though Kabir suggested that if we do want
>     to, say, allow
>      >>>>>>>> 7.x instances to be managed from an 8.x DC, that we should
>     create "stub"
>      >>>>>>>> extensions for the removed stuff that only carry and validate
>      >>>>>>>> configuration but aren't actually supported on 8.x
>     servers.  This seems
>      >>>>>>>> like a valid possibility to me.
>      >>>>>>>> --
>      >>>>>>>> - DML
>      >>>>>>>> _______________________________________________
>      >>>>>>>> jboss-as7-dev mailing list
>      >>>>>>>> [hidden email]
>     <mailto:[hidden email]>
>      >>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>      >>>>>>>
>      >>>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>      >>>>>>> Thomas Diesler
>      >>>>>>> JBoss OSGi Lead
>      >>>>>>> JBoss, a division of Red Hat
>      >>>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>      >>>>>>>
>      >>>>>>>
>      >>>>>>>
>      >>>>>>>
>      >>>>>>> _______________________________________________
>      >>>>>>> jboss-as7-dev mailing list
>      >>>>>>> [hidden email]
>     <mailto:[hidden email]>
>      >>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>      >>>>>>>
>      >>>>>>
>      >>>>>>
>      >>>>>
>      >>>>>
>      >>>>
>      >>>>
>      >>>
>      >>>
>      >>
>      >>
>      >
>      >
>
>
>     --
>     Brian Stansberry
>     Principal Software Engineer
>     JBoss by Red Hat
>     _______________________________________________
>     jboss-as7-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing JAXR & backward compatiblity

Tomaž Cerar-2
that is why i would suggest packaging this modules in special folder
under our distribution that would only be accessible by domain controller itself.

This way we make sure this modules only operate in MODEL stage.

Sure noting stops user from moving this modules to some other folder,
but he could also copy them from older version....

Other option would be to do model version checking, aka if module name is org.jboss.as.*
and major version is < 2 we would not allow runtime stage to be executed.
That brings some more complexity and forces us to bump major version for all subsystems


On Sat, Mar 2, 2013 at 12:15 AM, Brian Stansberry <[hidden email]> wrote:
When I say "find problems" I don't mean management problems. I mean runtime service bugs. If we ship the 7.2 CMP module and someone runs it on an AS8 server and reports an EJBQL parsing bug, how do we respond?


On 3/1/13 5:07 PM, Tomaž Cerar wrote:
hmm, given that DC only operates on MODEL/ADMIN  stage
there should no big issues if we make sure our model driven api is
compatible also in AS8.
I think that would be mostly jboss-as-controller and maybe few more.
But before I speculate, I should test my theory...
--
tomaz


On Fri, Mar 1, 2013 at 11:55 PM, Brian Stansberry
<[hidden email] <mailto:[hidden email]>> wrote:

    They have to have logic that prevents their use on an AS8 server.
    Unless we are willing to tell folks who use them on AS8 servers and
    find problems that they're out of luck and should know better.


    On 3/1/13 4:49 PM, Tomaž Cerar wrote:

        What about if we just use legacy extensions that would be loaded
        only on DC?
        for legacy i mean, why not just have modules / jars from 7.2 in
        8.0 distro?
        that would make it easiest to support, and no extra work.
        We should just put them in some special place in distro,
        so it would be obvious that is legacy stuff only DC uses...


        On Fri, Mar 1, 2013 at 11:44 PM, Brian Stansberry
        <[hidden email]
        <mailto:[hidden email]>
        <mailto:[hidden email]__redhat.com

        <mailto:[hidden email]>>> wrote:

             The extension registration logic would have to be altered
        to not barf
             when multiple aliases all try to register the same extensions/
             subsystems.

             But it probably should still barf if a user tried to do
        that for some
             other reason. So which is happening needs to be clarified.

             A way to do that is to use something other than
             org.jboss.as.controller.__Extension for the ServiceLoader

        (i.e. first try
             ServiceLoader for "LegacyExtension" and then if not there
        try for
             org.jboss.as.controller.__Extension.) That's hacky though

        unless there is
             a real difference in the service API between Extension and
        what these
             legacy extensions do. AFAICT though, there is no API
        difference;
             difference is only in impl.

             On 3/1/13 4:23 PM, David M. Lloyd wrote:
              > Rewinding the discussion a bit :)
              >
              > If we just had one compat module (with N pure aliases),
        it could
             easily
              > register all the subsystems for all the modules at that time
             (subsystem
              > registration is pretty lightweight these days, or so it
        seems at a
              > glance).  If extra subsystems are available as a result
        of an
             extension
              > reg I don't see that as harmless.
              >
              > On 03/01/2013 02:48 PM, Brian Stansberry wrote:
              >> I'm not sure how the ServiceLoader part would work
        there. At
             least not
              >> with what I imagine when I think of an "alias." With
        some kind
             of stub
              >> where each has a different
              >> META-INF/services/org.jboss.__as.controller.Extension

        file it
             could work.
              >>
              >> On 3/1/13 2:29 PM, David M. Lloyd wrote:
              >>> Yeah, I was thinking they could just be aliases or
        stubs though.
              >>>
              >>> On 03/01/2013 02:22 PM, Brian Stansberry wrote:
              >>>> In terms of code organization, perhaps. But the way the
             extension is
              >>>> activated in the HCs and servers is via the module
        name. So if
             you want
              >>>> a 7.2 server to be able to run CMP, there is going to
        have to be a
              >>>> module named org.jboss.as.cmp.
              >>>>
              >>>> On 3/1/13 2:13 PM, David M. Lloyd wrote:
              >>>>> I wonder - should we retain a skeletal version of
        each of
             these modules?
              >>>>>        I was thinking maybe it would be better to
        maintain
             one big
              >>>>> "removed-subsystems" or "compat-subsystems" module or
             something like
              >>>>> that where we can neatly/consistently organize all
        the model
             stuff for
              >>>>> these removals.
              >>>>>
              >>>>> On 03/01/2013 09:39 AM, Brian Stansberry wrote:
              >>>>>> Thanks Thomas, for raising this and for the JIRA.
              >>>>>>
              >>>>>> I've outlined what I think is needed for the stub
        extensions
             as a
              >>>>>> comment on
        https://issues.jboss.org/__browse/AS7-6656

        <https://issues.jboss.org/browse/AS7-6656> .
              >>>>>>
              >>>>>> Can I request that folks hold up on deleting these
             subsystems? I think
              >>>>>> it will be easier to make these changes and then
        delete the
             unneeded
              >>>>>> runtime stuff than it will be to semi-restore from
        history
             and then change.
              >>>>>>
              >>>>>> The ones that have already been deleted, it's no
        big deal.
              >>>>>>
              >>>>>> On 2/28/13 10:35 AM, Thomas Diesler wrote:
              >>>>>>> Ok, stub extensions is the obvious alternative to
        breaking
             compatibility. I'll leave this as a future task and create
        a jira
             for it if that's ok with you.
              >>>>>>>
              >>>>>>> cheers
              >>>>>>> --thomas
              >>>>>>>
              >>>>>>> On Feb 28, 2013, at 4:22 PM, David M. Lloyd
             <[hidden email] <mailto:[hidden email]>
        <mailto:[hidden email]

        <mailto:[hidden email]>__>> wrote:
              >>>>>>>
              >>>>>>>> On 02/28/2013 05:57 AM, Thomas Diesler wrote:
              >>>>>>>>> Folks,
              >>>>>>>>>
              >>>>>>>>> related to
              >>>>>>>>>
              >>>>>>>>> * [AS7-6612
        <https://issues.jboss.org/__browse/AS7-6612

        <https://issues.jboss.org/browse/AS7-6612>>]
             Remove JAXR support
              >>>>>>>>>
              >>>>>>>>> I'd like to know whether we need to preserve
        backward
             compatibility of
              >>>>>>>>> the configuration and if so what should happen
        if there
             is a jaxr config
              >>>>>>>>> item? Generally, can AS8 break backward
        compatibility
             with respect to
              >>>>>>>>> the config?
              >>>>>>>>
              >>>>>>>> Brian points out that we don't have a specific
        requirement
             to maintain
              >>>>>>>> compatibility with obsolete subsystems.  I think
        we could
             go ahead with
              >>>>>>>> the removal (granted part of the reason I feel
        this way is
             that I've
              >>>>>>>> already removed JSR-88...).
              >>>>>>>>
              >>>>>>>> Going forward though Kabir suggested that if we
        do want
             to, say, allow
              >>>>>>>> 7.x instances to be managed from an 8.x DC, that
        we should
             create "stub"
              >>>>>>>> extensions for the removed stuff that only carry
        and validate
              >>>>>>>> configuration but aren't actually supported on 8.x
             servers.  This seems
              >>>>>>>> like a valid possibility to me.
              >>>>>>>> --
              >>>>>>>> - DML
              >>>>>>>> _________________________________________________

              >>>>>>>> jboss-as7-dev mailing list
              >>>>>>>> [hidden email]
        <mailto:[hidden email]>
             <mailto:[hidden email]__jboss.org
        <mailto:[hidden email]>>

              >>>>>>>>
        https://lists.jboss.org/__mailman/listinfo/jboss-as7-dev

        <https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
              >>>>>>>
              >>>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
              >>>>>>> Thomas Diesler
              >>>>>>> JBoss OSGi Lead
              >>>>>>> JBoss, a division of Red Hat
              >>>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
              >>>>>>>
              >>>>>>>
              >>>>>>>
              >>>>>>>
              >>>>>>> _________________________________________________

              >>>>>>> jboss-as7-dev mailing list
              >>>>>>> [hidden email]
        <mailto:[hidden email]>
             <mailto:[hidden email]__jboss.org
        <mailto:[hidden email]>>

              >>>>>>>
        https://lists.jboss.org/__mailman/listinfo/jboss-as7-dev

        <https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
              >>>>>>>
              >>>>>>
              >>>>>>
              >>>>>
              >>>>>
              >>>>
              >>>>
              >>>
              >>>
              >>
              >>
              >
              >


             --
             Brian Stansberry
             Principal Software Engineer
             JBoss by Red Hat
             _________________________________________________

             jboss-as7-dev mailing list
        [hidden email]
        <mailto:[hidden email]>
        <mailto:[hidden email]__jboss.org
        <mailto:[hidden email]>>
        https://lists.jboss.org/__mailman/listinfo/jboss-as7-dev

        <https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>




    --
    Brian Stansberry
    Principal Software Engineer
    JBoss by Red Hat




--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing JAXR & backward compatiblity

David Lloyd-2
In reply to this post by Brian Stansberry
I agree with Brian.  This is simpler from a coding perspective, but it
is more complex from every other perspective.  I like Brian's
alternative service loader idea though.

On 03/01/2013 04:55 PM, Brian Stansberry wrote:

> They have to have logic that prevents their use on an AS8 server. Unless
> we are willing to tell folks who use them on AS8 servers and find
> problems that they're out of luck and should know better.
>
> On 3/1/13 4:49 PM, Tomaž Cerar wrote:
>> What about if we just use legacy extensions that would be loaded only on DC?
>> for legacy i mean, why not just have modules / jars from 7.2 in 8.0 distro?
>> that would make it easiest to support, and no extra work.
>> We should just put them in some special place in distro,
>> so it would be obvious that is legacy stuff only DC uses...
>>
>>
>> On Fri, Mar 1, 2013 at 11:44 PM, Brian Stansberry
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>      The extension registration logic would have to be altered to not barf
>>      when multiple aliases all try to register the same extensions/
>>      subsystems.
>>
>>      But it probably should still barf if a user tried to do that for some
>>      other reason. So which is happening needs to be clarified.
>>
>>      A way to do that is to use something other than
>>      org.jboss.as.controller.Extension for the ServiceLoader (i.e. first try
>>      ServiceLoader for "LegacyExtension" and then if not there try for
>>      org.jboss.as.controller.Extension.) That's hacky though unless there is
>>      a real difference in the service API between Extension and what these
>>      legacy extensions do. AFAICT though, there is no API difference;
>>      difference is only in impl.
>>
>>      On 3/1/13 4:23 PM, David M. Lloyd wrote:
>>       > Rewinding the discussion a bit :)
>>       >
>>       > If we just had one compat module (with N pure aliases), it could
>>      easily
>>       > register all the subsystems for all the modules at that time
>>      (subsystem
>>       > registration is pretty lightweight these days, or so it seems at a
>>       > glance).  If extra subsystems are available as a result of an
>>      extension
>>       > reg I don't see that as harmless.
>>       >
>>       > On 03/01/2013 02:48 PM, Brian Stansberry wrote:
>>       >> I'm not sure how the ServiceLoader part would work there. At
>>      least not
>>       >> with what I imagine when I think of an "alias." With some kind
>>      of stub
>>       >> where each has a different
>>       >> META-INF/services/org.jboss.as.controller.Extension file it
>>      could work.
>>       >>
>>       >> On 3/1/13 2:29 PM, David M. Lloyd wrote:
>>       >>> Yeah, I was thinking they could just be aliases or stubs though.
>>       >>>
>>       >>> On 03/01/2013 02:22 PM, Brian Stansberry wrote:
>>       >>>> In terms of code organization, perhaps. But the way the
>>      extension is
>>       >>>> activated in the HCs and servers is via the module name. So if
>>      you want
>>       >>>> a 7.2 server to be able to run CMP, there is going to have to be a
>>       >>>> module named org.jboss.as.cmp.
>>       >>>>
>>       >>>> On 3/1/13 2:13 PM, David M. Lloyd wrote:
>>       >>>>> I wonder - should we retain a skeletal version of each of
>>      these modules?
>>       >>>>>        I was thinking maybe it would be better to maintain
>>      one big
>>       >>>>> "removed-subsystems" or "compat-subsystems" module or
>>      something like
>>       >>>>> that where we can neatly/consistently organize all the model
>>      stuff for
>>       >>>>> these removals.
>>       >>>>>
>>       >>>>> On 03/01/2013 09:39 AM, Brian Stansberry wrote:
>>       >>>>>> Thanks Thomas, for raising this and for the JIRA.
>>       >>>>>>
>>       >>>>>> I've outlined what I think is needed for the stub extensions
>>      as a
>>       >>>>>> comment on https://issues.jboss.org/browse/AS7-6656 .
>>       >>>>>>
>>       >>>>>> Can I request that folks hold up on deleting these
>>      subsystems? I think
>>       >>>>>> it will be easier to make these changes and then delete the
>>      unneeded
>>       >>>>>> runtime stuff than it will be to semi-restore from history
>>      and then change.
>>       >>>>>>
>>       >>>>>> The ones that have already been deleted, it's no big deal.
>>       >>>>>>
>>       >>>>>> On 2/28/13 10:35 AM, Thomas Diesler wrote:
>>       >>>>>>> Ok, stub extensions is the obvious alternative to breaking
>>      compatibility. I'll leave this as a future task and create a jira
>>      for it if that's ok with you.
>>       >>>>>>>
>>       >>>>>>> cheers
>>       >>>>>>> --thomas
>>       >>>>>>>
>>       >>>>>>> On Feb 28, 2013, at 4:22 PM, David M. Lloyd
>>      <[hidden email] <mailto:[hidden email]>> wrote:
>>       >>>>>>>
>>       >>>>>>>> On 02/28/2013 05:57 AM, Thomas Diesler wrote:
>>       >>>>>>>>> Folks,
>>       >>>>>>>>>
>>       >>>>>>>>> related to
>>       >>>>>>>>>
>>       >>>>>>>>> * [AS7-6612 <https://issues.jboss.org/browse/AS7-6612>]
>>      Remove JAXR support
>>       >>>>>>>>>
>>       >>>>>>>>> I'd like to know whether we need to preserve backward
>>      compatibility of
>>       >>>>>>>>> the configuration and if so what should happen if there
>>      is a jaxr config
>>       >>>>>>>>> item? Generally, can AS8 break backward compatibility
>>      with respect to
>>       >>>>>>>>> the config?
>>       >>>>>>>>
>>       >>>>>>>> Brian points out that we don't have a specific requirement
>>      to maintain
>>       >>>>>>>> compatibility with obsolete subsystems.  I think we could
>>      go ahead with
>>       >>>>>>>> the removal (granted part of the reason I feel this way is
>>      that I've
>>       >>>>>>>> already removed JSR-88...).
>>       >>>>>>>>
>>       >>>>>>>> Going forward though Kabir suggested that if we do want
>>      to, say, allow
>>       >>>>>>>> 7.x instances to be managed from an 8.x DC, that we should
>>      create "stub"
>>       >>>>>>>> extensions for the removed stuff that only carry and validate
>>       >>>>>>>> configuration but aren't actually supported on 8.x
>>      servers.  This seems
>>       >>>>>>>> like a valid possibility to me.
>>       >>>>>>>> --
>>       >>>>>>>> - DML
>>       >>>>>>>> _______________________________________________
>>       >>>>>>>> jboss-as7-dev mailing list
>>       >>>>>>>> [hidden email]
>>      <mailto:[hidden email]>
>>       >>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>       >>>>>>>
>>       >>>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>       >>>>>>> Thomas Diesler
>>       >>>>>>> JBoss OSGi Lead
>>       >>>>>>> JBoss, a division of Red Hat
>>       >>>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>       >>>>>>>
>>       >>>>>>>
>>       >>>>>>>
>>       >>>>>>>
>>       >>>>>>> _______________________________________________
>>       >>>>>>> jboss-as7-dev mailing list
>>       >>>>>>> [hidden email]
>>      <mailto:[hidden email]>
>>       >>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>       >>>>>>>
>>       >>>>>>
>>       >>>>>>
>>       >>>>>
>>       >>>>>
>>       >>>>
>>       >>>>
>>       >>>
>>       >>>
>>       >>
>>       >>
>>       >
>>       >
>>
>>
>>      --
>>      Brian Stansberry
>>      Principal Software Engineer
>>      JBoss by Red Hat
>>      _______________________________________________
>>      jboss-as7-dev mailing list
>>      [hidden email] <mailto:[hidden email]>
>>      https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>
>


--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev