[jboss-as7-dev] Removing JAXR & backward compatiblity
Brian Stansberry
brian.stansberry at redhat.com
Fri Mar 1 16:59:51 EST 2013
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
>>> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> 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
>>> <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>> 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
>>> >>>>>> jboss-as7-dev at lists.jboss.org
>>> <mailto:jboss-as7-dev at lists.jboss.org>
>>> >>>>>> 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
>>> >>>>> jboss-as7-dev at lists.jboss.org
>>> <mailto:jboss-as7-dev at lists.jboss.org>
>>> >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org <mailto:jboss-as7-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>>
>>
>>
>
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
More information about the jboss-as7-dev
mailing list