[jboss-as7-dev] Removing JAXR & backward compatiblity
David M. Lloyd
david.lloyd at redhat.com
Sat Mar 2 10:32:13 EST 2013
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
>> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> 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
>> <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