[jboss-as7-dev] Removing JAXR & backward compatiblity
Tomaž Cerar
tomaz.cerar at gmail.com
Fri Mar 1 18:46:56 EST 2013
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 <
brian.stansberry at redhat.com> 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
>> <brian.stansberry at redhat.com <mailto:brian.stansberry@**redhat.com<brian.stansberry at 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 at redhat.com
>> <mailto:brian.stansberry@**redhat.com<brian.stansberry at redhat.com>
>> >
>> <mailto:brian.stansberry at __red**hat.com <http://redhat.com>
>>
>> <mailto:brian.stansberry@**redhat.com<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<https://issues.jboss.org/__browse/AS7-6656>
>>
>> <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
>> <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com**>
>> <mailto: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<https://issues.jboss.org/__browse/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
>> >>>>>>>> jboss-as7-dev at lists.jboss.org
>> <mailto:jboss-as7-dev at lists.**jboss.org<jboss-as7-dev at lists.jboss.org>
>> >
>> <mailto:jboss-as7-dev at lists.__**jboss.org <http://jboss.org>
>> <mailto:jboss-as7-dev at lists.**jboss.org<jboss-as7-dev at lists.jboss.org>
>> >>
>>
>> >>>>>>>>
>> https://lists.jboss.org/__**mailman/listinfo/jboss-as7-dev<https://lists.jboss.org/__mailman/listinfo/jboss-as7-dev>
>>
>> <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
>> >>>>>>> jboss-as7-dev at lists.jboss.org
>> <mailto:jboss-as7-dev at lists.**jboss.org<jboss-as7-dev at lists.jboss.org>
>> >
>> <mailto:jboss-as7-dev at lists.__**jboss.org <http://jboss.org>
>> <mailto:jboss-as7-dev at lists.**jboss.org<jboss-as7-dev at lists.jboss.org>
>> >>
>>
>> >>>>>>>
>> https://lists.jboss.org/__**mailman/listinfo/jboss-as7-dev<https://lists.jboss.org/__mailman/listinfo/jboss-as7-dev>
>>
>> <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
>> jboss-as7-dev at lists.jboss.org
>> <mailto:jboss-as7-dev at lists.**jboss.org<jboss-as7-dev at lists.jboss.org>
>> >
>> <mailto:jboss-as7-dev at lists.__**jboss.org <http://jboss.org>
>> <mailto:jboss-as7-dev at lists.**jboss.org<jboss-as7-dev at lists.jboss.org>
>> >>
>> https://lists.jboss.org/__**mailman/listinfo/jboss-as7-dev<https://lists.jboss.org/__mailman/listinfo/jboss-as7-dev>
>>
>> <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20130302/3e223a76/attachment-0001.html
More information about the jboss-as7-dev
mailing list