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 > <brian.stansberry(a)redhat.com <mailto:brian.stansberry@**redhat.com<brian.stansberry@redhat.com>>> > 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(a)redhat.com > <mailto:brian.stansberry@**redhat.com<brian.stansberry@redhat.com> > > > <mailto:brian.stansberry@__red**hat.com <http://redhat.com> > > <mailto:brian.stansberry@**redhat.com<brian.stansberry@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<https://issues.jboss.org/... > > <https://issues.jboss.org/**browse/AS7-6656<https://issues.jboss.org/br... > . > >>>>>> > >>>>>> 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(a)redhat.com <mailto:david.lloyd@redhat.com**> > <mailto:david.lloyd@redhat.com > > <mailto:david.lloyd@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<https://issues.jboss.org/... > > <https://issues.jboss.org/**browse/AS7-6612<https://issues.jboss.org/br... > >>] > 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(a)lists.jboss.org > <mailto:jboss-as7-dev@lists.**jboss.org<jboss-as7-dev@lists.jboss.org> > > > <mailto:jboss-as7-dev@lists.__**jboss.org <http://jboss.org> > <mailto:jboss-as7-dev@lists.**jboss.org<jboss-as7-dev@lists.jboss.org> > >> > > >>>>>>>> > https://lists.jboss.org/__**mailman/listinfo/jboss-as7-dev<https://lis... > > <https://lists.jboss.org/**mailman/listinfo/jboss-as7-dev<https://lists... > **> > >>>>>>> > >>>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx > >>>>>>> Thomas Diesler > >>>>>>> JBoss OSGi Lead > >>>>>>> JBoss, a division of Red Hat > >>>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ______________________________**___________________ > > >>>>>>> jboss-as7-dev mailing list > >>>>>>> jboss-as7-dev(a)lists.jboss.org > <mailto:jboss-as7-dev@lists.**jboss.org<jboss-as7-dev@lists.jboss.org> > > > <mailto:jboss-as7-dev@lists.__**jboss.org <http://jboss.org> > <mailto:jboss-as7-dev@lists.**jboss.org<jboss-as7-dev@lists.jboss.org> > >> > > >>>>>>> > https://lists.jboss.org/__**mailman/listinfo/jboss-as7-dev<https://lis... > > <https://lists.jboss.org/**mailman/listinfo/jboss-as7-dev<https://lists... > **> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > > > > -- > Brian Stansberry > Principal Software Engineer > JBoss by Red Hat > ______________________________**___________________ > > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > <mailto:jboss-as7-dev@lists.**jboss.org<jboss-as7-dev@lists.jboss.org> > > > <mailto:jboss-as7-dev@lists.__**jboss.org <http://jboss.org> > <mailto:jboss-as7-dev@lists.**jboss.org<jboss-as7-dev@lists.jboss.org> > >> > https://lists.jboss.org/__**mailman/listinfo/jboss-as7-dev<https://lis... > > <https://lists.jboss.org/**mailman/listinfo/jboss-as7-dev<https://lists... > **> > > > > > -- > Brian Stansberry > Principal Software Engineer > JBoss by Red Hat > > > -- Brian Stansberry Principal Software Engineer JBoss by Red Hat