[jboss-as7-dev] Removing JAXR & backward compatiblity

David M. Lloyd david.lloyd at redhat.com
Fri Mar 1 16:25:17 EST 2013


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
>>
>>
>
>


-- 
- DML


More information about the jboss-as7-dev mailing list