[jboss-as7-dev] Subsystem model version for AS8
Kabir Khan
kabir.khan at jboss.com
Tue Mar 5 14:29:13 EST 2013
We have the testsuite/mixed-domain module which is currently quite empty but which tests like this could be added to
On 5 Mar 2013, at 18:45, Scott Marlow wrote:
> On 03/05/2013 10:55 AM, Jaikiran Pai wrote:
>> I might be wrong, but I haven't seen tests for these in EAP6/AS7. Do we
>> have them somewhere? I do plan to add some for EJB invocations between
>> different AS versions of AS7/8.
>
> Do we have any external projects that currently do any AS testing from
> their testsuites (perhaps building AS7/AS8 from git repo source) and
> kicking off Arquillian tests? I assume you meant that you would test
> EJB invocations between AS7/AS8 manually but am also wondering what is
> possible for test automation.
>
>>
>> -Jaikiran
>> On Tuesday 05 March 2013 09:22 PM, Andrig Miller wrote:
>>> I would too, and I would add something as well.
>>>
>>> For some customers, we have agreed to keep JMS clients compatible across three major releases. So, and EAP 5.x client should be able to work with EAP 6 and EAP 7.
>>>
>>> So, this means that not only the API has to be compatible, but the wire protocols have to continue to work. Things like JNDI usage for a JMS client has to continue to work.
>>>
>>> This is a big deal, and its in these customers contracts for their EAP subscriptions.
>>>
>>> Andy
>>>
>>> ----- Original Message -----
>>>> From: "David M. Lloyd" <david.lloyd at redhat.com>
>>>> To: jboss-as7-dev at lists.jboss.org
>>>> Sent: Monday, March 4, 2013 11:51:54 AM
>>>> Subject: Re: [jboss-as7-dev] Subsystem model version for AS8
>>>>
>>>> I agree with Brian 100% on all points, FWIW.
>>>>
>>>> On 03/04/2013 12:38 PM, Brian Stansberry wrote:
>>>>> I think continuing to address specific problems is important. For a
>>>>> number of reasons:
>>>>>
>>>>> 1) The standards we're trying to set for backwards compatibility
>>>>> IMHO
>>>>> need to keep increasing. My impression from discussions with the
>>>>> business side people behind EAP is that they agree. At some point
>>>>> we're
>>>>> going to need to be able to support some form of domain management
>>>>> across major product versions. I'd rather we work incrementally
>>>>> toward
>>>>> that by solving problems rather than punting and then have to
>>>>> figure out
>>>>> all the problems when someone forces the requirement.
>>>>>
>>>>> As an example, the current discussion on figuring out how to deal
>>>>> with
>>>>> deleted subsystems like CMP is useful. Similarly, I think it will
>>>>> be
>>>>> useful to figure out how to deal with a radical transition in a
>>>>> subsystem, a la what might happen with the web subsystem. Clearly
>>>>> we
>>>>> can't transform completely incompatible configs, but can both
>>>>> variations
>>>>> co-exist in a domain, with legacy server-groups running legacy
>>>>> profiles
>>>>> and other server groups running newer configs? That should be a
>>>>> solvable
>>>>> problem.
>>>>>
>>>>> 2) I fully expect demands to port AS 8 features back into EAP 6.
>>>>> It's
>>>>> going to happen. When it does, the compatibility requirement will
>>>>> suddenly appear. Better to address it when the feature is written
>>>>> than
>>>>> to expect people less familiar with the problem to add it during a
>>>>> port.
>>>>>
>>>>> 3) Transformation is a somewhat separate issue from backward
>>>>> compatibility for management clients, but we've found that doing
>>>>> and
>>>>> testing the transformation is real helpful in identifying client
>>>>> compatibility problems. Client compatibility is real important.
>>>>> We've
>>>>> promised many times that we won't willy-nilly break the client APIs
>>>>> even
>>>>> across major versions, so we need some kind of enforcement that
>>>>> we're
>>>>> not doing that.
>>>>>
>>>>> 4) I think the AS is going to be moving toward more rapid major
>>>>> releases. If we use each of those as an opportunity to break
>>>>> compatibility at will, our software will be uselessly unstable, and
>>>>> when
>>>>> the time comes to restore some compatibility guarantees for EAP,
>>>>> the
>>>>> task will be impossible.
>>>>>
>>>>> I also hope that given we're two years into the life of our
>>>>> subsystems
>>>>> that the "rapidly evolving" nature for most of their management
>>>>> APIs is
>>>>> about at an end. That should have been the case a year ago.
>>>>> Obviously
>>>>> there will always be new things getting added.
>>>>>
>>>>> On 3/4/13 9:02 AM, Paul Ferraro wrote:
>>>>>> It's not that there's a problem - it's just that we can't maintain
>>>>>> backwards compatibility indefinitely, since the work required to
>>>>>> do so grows exponentially (for rapidly evolving subsystems). A
>>>>>> major version bump seems like a natural breaking point -
>>>>>> otherwise, what is the significance of incrementing to 2.0?
>>>>>> TBH - I mostly ask because I'm lazy and don't want to write
>>>>>> transformers if I don't have to...
>>>>>>
>>>>>> Paul
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Brian Stansberry" <brian.stansberry at redhat.com>
>>>>>>> To: "Paul Ferraro" <paul.ferraro at redhat.com>
>>>>>>> Cc: "JBoss AS7 Development" <jboss-as7-dev at lists.jboss.org>,
>>>>>>> "Tomaž Cerar" <tomaz.cerar at gmail.com>
>>>>>>> Sent: Wednesday, February 27, 2013 8:23:26 PM
>>>>>>> Subject: Re: [jboss-as7-dev] Subsystem model version for AS8
>>>>>>>
>>>>>>> What's the problem going to be?
>>>>>>>
>>>>>>> On 2/27/13 7:10 PM, Paul Ferraro wrote:
>>>>>>>> Do the 2.x model versions need to be backwards compatible with
>>>>>>>> 1.x
>>>>>>>> versions?
>>>>>>>> i.e. Do we need transformers to support a domain with mixed
>>>>>>>> major
>>>>>>>> versions?
>>>>>>>> I hope not.
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Brian Stansberry" <brian.stansberry at redhat.com>
>>>>>>>>> To: "Tomaž Cerar" <tomaz.cerar at gmail.com>
>>>>>>>>> Cc: "JBoss AS7 Development" <jboss-as7-dev at lists.jboss.org>
>>>>>>>>> Sent: Monday, February 25, 2013 10:30:24 AM
>>>>>>>>> Subject: Re: [jboss-as7-dev] Subsystem model version for AS8
>>>>>>>>>
>>>>>>>>> Yes.
>>>>>>>>>
>>>>>>>>> On 2/25/13 9:24 AM, Tomaž Cerar wrote:
>>>>>>>>>> What about XSD schemas?
>>>>>>>>>>
>>>>>>>>>> probably same rule?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Feb 25, 2013 at 3:00 PM, Brian Stansberry
>>>>>>>>>> <brian.stansberry at redhat.com
>>>>>>>>>> <mailto:brian.stansberry at redhat.com>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Yes, major version bump please. This makes it
>>>>>>>>>> straightforward
>>>>>>>>>> to avoid
>>>>>>>>>> version conflicts with EAP 6.x. If EAP 6.x needs to
>>>>>>>>>> change
>>>>>>>>>> API
>>>>>>>>>> in more
>>>>>>>>>> than a bug fix way, they can use a minor version with
>>>>>>>>>> no
>>>>>>>>>> fear
>>>>>>>>>> that
>>>>>>>>>> community AS has already used that # for something
>>>>>>>>>> else.
>>>>>>>>>>
>>>>>>>>>> On 2/25/13 7:11 AM, Tomaž Cerar wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I remember few discussions on IRC in last weeks(s)
>>>>>>>>>>> about
>>>>>>>>>>> how
>>>>>>>>>>> to
>>>>>>>>>> handle
>>>>>>>>>>> version bumps for subsystem model when changes are
>>>>>>>>>>> done
>>>>>>>>>>> on
>>>>>>>>>>> AS8
>>>>>>>>>> codebase.
>>>>>>>>>>>
>>>>>>>>>>> It was somewhat agreed that instead of bumping minor
>>>>>>>>>>> version
>>>>>>>>>>> we
>>>>>>>>>> should
>>>>>>>>>>> upgrade major version.
>>>>>>>>>>>
>>>>>>>>>>> aka instead of doing 1.2 --> 1.3, new version should
>>>>>>>>>>> be
>>>>>>>>>>> 2.0
>>>>>>>>>>>
>>>>>>>>>>> That gives us flexibility of bumping minor version
>>>>>>>>>>> to 7.x
>>>>>>>>>>> codebase if
>>>>>>>>>>> need arises.
>>>>>>>>>>>
>>>>>>>>>>> I am writing this as there was some PRs lately that
>>>>>>>>>>> bump
>>>>>>>>>>> just
>>>>>>>>>> minor version.
>>>>>>>>>>>
>>>>>>>>>>> So, can we get an agreement of new versioning rules,
>>>>>>>>>>> that
>>>>>>>>>>> we
>>>>>>>>>>> will
>>>>>>>>>> then
>>>>>>>>>>> follow.
>>>>>>>>>>>
>>>>>>>>>>> I personalty favor major version bumps...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> tomaz
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>>>>> _______________________________________________
>>>>>>>>> jboss-as7-dev mailing list
>>>>>>>>> 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
>>>>>>>
>>>>>
>>>>
>>>> --
>>>> - DML
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
---------------------------------------
Kabir Khan
Prinicipal Software Engineer
JBoss by Red Hat
More information about the jboss-as7-dev
mailing list