I've been trying to implement a new feature which requires the addition of a new model attribute for the EJB3 subsystem root resource. This model attribute is supposed to be "mandatory" (i.e. non-nullable at model level and "required" at xml level). All works fine without bringing into picture older versions of the model. Now while testing with older versions of the model and compatibility, things start failing for obvious reasons- the older model handlers, parsers etc... have no clue about this new attribute. I'm aware that that's where the

transformers come into picture and I've setup an appropriate transformer that is supposed to handle this scenario. But, the transformers tests in EJB3SubsystemUnitTestCase fails for different test methods. I had to dig a bit into the code to figure out that one of the failures had to do with the test case itself rather than the new code. One part of the problem and the main reason why I decided to ask this via a mail instead of over IRC is because, I've been having a difficult time with the transformer APIs and its usage. On a higher level I (think) I do understand what the transformers are supposed to do and how to deal with individual attribute/resource changes when multiple versions of the model come into picture. But when it comes to wiring the right transformers at the right place in the code or figuring out what such places are or even debugging failing tests, I find it not so straightforward to understand what's going on. Perhaps it's just that I am not yet used to those APIs. To be honest, with whatever transformer code I've added, although it seems to work to a certain extent, I'm not confident about the code I'm adding - I've been just looking at other places and copying over the code wherever appropriate. So back to the original issue and the related question - would it be possible to "automate" this process of plugging in these transformers? In this specific case, for example, I think almost all (there maybe be exceptions) subsystems and resources introducing a new attribute in the higher model would expect that that attribute to be ignored (I'm not using the term discarded or rejected because I am not 100% sure I understand the difference yet :) ) by lower versions of the model.

So instead of me trying to figure out where to plugin these transformers, would it be possible to *dynamically* generate these transformers for some of these cases? That way I wouldn't have to deal with these for every new attribute and instead be assured that this would be handled centrally at some place?

P.S: If someone wants to take a look at the (failing WIP) code that I'm talking about, then let me know, I can push my code to github. I wanted to keep this mail to be broader than just this specific failing case. -Jaikiran _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On Tuesday 05 March 2013 08:24 PM, Kabir Khan wrote: > On 5 Mar 2013, at 14:23, Jaikiran Pai wrote: > >> I've been trying to implement a new feature which requires the addition >> of a new model attribute for the EJB3 subsystem root resource. This >> model attribute is supposed to be "mandatory" (i.e. non-nullable at >> model level and "required" at xml level). All works fine without >> bringing into picture older versions of the model. Now while testing >> with older versions of the model and compatibility, things start failing >> for obvious reasons- the older model handlers, parsers etc... have no >> clue about this new attribute. I'm aware that that's where the > The old parsers should make it possible to construct the current model. Is the new attribute something which is now configurable, so you have two choices whereas previously one of those choices was assumed? In that case I think the old parser should create the resulting operation with the assumed default. The new (xml and model) attribute that I'm introducing is for EJB 3.2 spec support. This attribute had no semantics in the previous model versions. So this is a completely new one in terms of semantics. >> subsystems and resources introducing a new attribute in the >> higher model would expect that that attribute to be ignored (I'm not >> using the term discarded or rejected because I am not 100% sure I >> understand the difference yet :) ) by lower versions of the model. > discard = silently discard the attribute > reject = if the attribute is used/does not have some value/is defined/other conditions the transformation should fail > > Normally we prefer reject. So for your case, again assuming that the added attribute has some assumed value in the old version, you should fail transformation if the current model does not have that assumed value. Sorry, my initial mail didn't have the attribute specifics. This new attribute is a EJB 3.2 specific thing so I think "discard" would be applicable in this case.

This looks less like a 'switch' than an ability to specify how something which must be there is used, so perhaps a discard is ok in this case (it is the passivation-disabled-cache-ref attribute): <session-bean> --SNIP-- <stateful default-access-timeout="${prop.default-access-timeout:5000}" cache-ref="file" clustered-cache-ref="cluster" passivation-disabled-cache-ref="simple"/> --SNIP-- <caches> <cache name="simple"/> <cache name="passivating" passivation-store-ref="file"/> <cache name="clustered" passivation-store-ref="cluster"/> </caches> In other words the passivation-disabled-cache-ref will always be set on AS 8, and there is no default/assumed 'value that can be used to determine to reject on AS7.x. I'm not familiar with this part of the EJB 3.2 spec https://github.com/jaikiran/jboss-as/commit/3fe390d39256eeac06c682ef8ea06... so I don't know how the passivation is turned off for individual beans in an actual deployment. It sort of looks to me as if anybody tries to deploy beans using this new functionality to a server group containing 7.x slaves that the actual deployment should be rejected rather than handled at the subsystem model level? I don't think we have anything in place to inspect deployments on the DC before sending to the slaves, AFAICR we just store the deployments in the repository and submit that data when a slave requests it following a deployment to its server group. I am not sure if it fail on the slave if attempted used? This will probably affect other new features in the EE 7 spec which are not handled by EE 6/AS 7.x as well. On 5 Mar 2013, at 15:21, Brian Stansberry wrote: > On 3/5/13 9:14 AM, Jaikiran Pai wrote: >> On Tuesday 05 March 2013 08:24 PM, Kabir Khan wrote: >>> On 5 Mar 2013, at 14:23, Jaikiran Pai wrote: >>> >>>> I've been trying to implement a new feature which requires the addition >>>> of a new model attribute for the EJB3 subsystem root resource. This >>>> model attribute is supposed to be "mandatory" (i.e. non-nullable at >>>> model level and "required" at xml level). All works fine without >>>> bringing into picture older versions of the model. Now while testing >>>> with older versions of the model and compatibility, things start failing >>>> for obvious reasons- the older model handlers, parsers etc... have no >>>> clue about this new attribute. I'm aware that that's where the >>> The old parsers should make it possible to construct the current model. Is the new attribute something which is now configurable, so you have two choices whereas previously one of those choices was assumed? In that case I think the old parser should create the resulting operation with the assumed default. >> The new (xml and model) attribute that I'm introducing is for EJB 3.2 >> spec support. This attribute had no semantics in the previous model >> versions. So this is a completely new one in terms of semantics. >> >>>> subsystems and resources introducing a new attribute in the >>>> higher model would expect that that attribute to be ignored (I'm not >>>> using the term discarded or rejected because I am not 100% sure I >>>> understand the difference yet :) ) by lower versions of the model. >>> discard = silently discard the attribute >>> reject = if the attribute is used/does not have some value/is defined/other conditions the transformation should fail >>> >>> Normally we prefer reject. So for your case, again assuming that the added attribute has some assumed value in the old version, you should fail transformation if the current model does not have that assumed value. >> Sorry, my initial mail didn't have the attribute specifics. This new >> attribute is a EJB 3.2 specific thing so I think "discard" would be >> applicable in this case. >> > > Probably not. > > The cardinal rule is, the servers running on the legacy version must run > consistently with other servers running the new version. If they cannot > (because they don't understand some new piece of config), a reject is > necessary, and the legacy servers must ignore the profile. > > The goal is not to hide unresolvable configuration incompatibilities. > > > -- > Brian Stansberry > Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev --------------------------------------- Kabir Khan Prinicipal Software Engineer JBoss by Red Hat

Is this really a required attribute? If you want to use this feature, sure it's required. But if you don't why should you have to configure this? On 3/5/13 5:08 PM, Kabir Khan wrote: > And again since there is no default, it is hard to know which cache the old parsers should default to. Again, deployments trying to use this new stuff should probably fail in that case. If the attribute was nillable and not set that would get around the parser problem but would mean not being able to deploy beans wanting to turn off passivation. > On 5 Mar 2013, at 23:05, Kabir Khan wrote: > >> This looks less like a 'switch' than an ability to specify how something which must be there is used, so perhaps a discard is ok in this case (it is the passivation-disabled-cache-ref attribute): >> >> <session-bean> >> --SNIP-- >> <stateful default-access-timeout="${prop.default-access-timeout:5000}" cache-ref="file" clustered-cache-ref="cluster" passivation-disabled-cache-ref="simple"/> >> --SNIP-- >> <caches> >> <cache name="simple"/> >> <cache name="passivating" passivation-store-ref="file"/> >> <cache name="clustered" passivation-store-ref="cluster"/> >> </caches> >> >> In other words the passivation-disabled-cache-ref will always be set on AS 8, and there is no default/assumed 'value that can be used to determine to reject on AS7.x. I'm not familiar with this part of the EJB 3.2 spec https://github.com/jaikiran/jboss-as/commit/3fe390d39256eeac06c682ef8ea06... so I don't know how the passivation is turned off for individual beans in an actual deployment. It sort of looks to me as if anybody tries to deploy beans using this new functionality to a server group containing 7.x slaves that the actual deployment should be rejected rather than handled at the subsystem model level? I don't think we have anything in place to inspect deployments on the DC before sending to the slaves, AFAICR we just store the deployments in the repository and submit that data when a slave requests it following a deployment to its server group. I am not sure if it fail on the slave if attempted used? This will probably affect other new features in th! e EE 7 spe c which are not handled by EE 6/AS 7.x as well. >> On 5 Mar 2013, at 15:21, Brian Stansberry wrote: >> >>> On 3/5/13 9:14 AM, Jaikiran Pai wrote: >>>> On Tuesday 05 March 2013 08:24 PM, Kabir Khan wrote: >>>>> On 5 Mar 2013, at 14:23, Jaikiran Pai wrote: >>>>> >>>>>> I've been trying to implement a new feature which requires the addition >>>>>> of a new model attribute for the EJB3 subsystem root resource. This >>>>>> model attribute is supposed to be "mandatory" (i.e. non-nullable at >>>>>> model level and "required" at xml level). All works fine without >>>>>> bringing into picture older versions of the model. Now while testing >>>>>> with older versions of the model and compatibility, things start failing >>>>>> for obvious reasons- the older model handlers, parsers etc... have no >>>>>> clue about this new attribute. I'm aware that that's where the >>>>> The old parsers should make it possible to construct the current model. Is the new attribute something which is now configurable, so you have two choices whereas previously one of those choices was assumed? In that case I think the old parser should create the resulting operation with the assumed default. >>>> The new (xml and model) attribute that I'm introducing is for EJB 3.2 >>>> spec support. This attribute had no semantics in the previous model >>>> versions. So this is a completely new one in terms of semantics. >>>> >>>>>> subsystems and resources introducing a new attribute in the >>>>>> higher model would expect that that attribute to be ignored (I'm not >>>>>> using the term discarded or rejected because I am not 100% sure I >>>>>> understand the difference yet :) ) by lower versions of the model. >>>>> discard = silently discard the attribute >>>>> reject = if the attribute is used/does not have some value/is defined/other conditions the transformation should fail >>>>> >>>>> Normally we prefer reject. So for your case, again assuming that the added attribute has some assumed value in the old version, you should fail transformation if the current model does not have that assumed value. >>>> Sorry, my initial mail didn't have the attribute specifics. This new >>>> attribute is a EJB 3.2 specific thing so I think "discard" would be >>>> applicable in this case. >>>> >>> Probably not. >>> >>> The cardinal rule is, the servers running on the legacy version must run >>> consistently with other servers running the new version. If they cannot >>> (because they don't understand some new piece of config), a reject is >>> necessary, and the legacy servers must ignore the profile. >>> >>> The goal is not to hide unresolvable configuration incompatibilities. >>> >>> >>> -- >>> Brian Stansberry >>> Principal Software Engineer >>> JBoss by Red Hat >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> --------------------------------------- >> Kabir Khan >> Prinicipal Software Engineer >> JBoss by Red Hat >> > --------------------------------------- > Kabir Khan > Prinicipal Software Engineer > JBoss by Red Hat >

Seems to me the admin has to set it up anyway. We can provide this in our default configs -- in which case the admin has set it up by not changing anything. ;)

But otherwise this attribute is just a ref to another resource that will have to be created by an admin. Note that there is no requirement that the standard configs we ship can be transformed into something usable by a legacy slave. On 3/5/13 10:41 PM, Jaikiran Pai wrote: > Hi Brian, > > I'm still catching up with the other replies, but just to answer this > one quickly - I did think about it before deciding that this should be a > required attribute. My reasoning for that is - the EJB 3.2 spec mandates > that if a user deployment for a EJB says that the SFSB is disabled for > passivation, then the EJB container *must* be able to handle that. That > IMO, effectively translates to a requirement that for the EJB3 subsystem > to be EJB 3.2 compliant it *must* always have a passivation disabled > cache whether or not there are SFSB deployments which want to disable > passivation. We could make this attribute optional but then, if and when > some deployment has a passivation disabled SFSB, then the user has to > ask the admin to set this attribute up, so that the deployment works as > expected. > > Since this is a subsystem level attribute, to me it looked right to mark > it as a required attribute to let the EJB3 subsystem be EJB 3.2 > compliant always. > > -Jaikiran > On Wednesday 06 March 2013 05:00 AM, Brian Stansberry wrote: >> Is this really a required attribute? >> >> If you want to use this feature, sure it's required. But if you don't >> why should you have to configure this? >> >> On 3/5/13 5:08 PM, Kabir Khan wrote: >>> And again since there is no default, it is hard to know which cache the old parsers should default to. Again, deployments trying to use this new stuff should probably fail in that case. If the attribute was nillable and not set that would get around the parser problem but would mean not being able to deploy beans wanting to turn off passivation. >>> On 5 Mar 2013, at 23:05, Kabir Khan wrote: >>> >>>> This looks less like a 'switch' than an ability to specify how something which must be there is used, so perhaps a discard is ok in this case (it is the passivation-disabled-cache-ref attribute): >>>> >>>> <session-bean> >>>> --SNIP-- >>>> <stateful default-access-timeout="${prop.default-access-timeout:5000}" cache-ref="file" clustered-cache-ref="cluster" passivation-disabled-cache-ref="simple"/> >>>> --SNIP-- >>>> <caches> >>>> <cache name="simple"/> >>>> <cache name="passivating" passivation-store-ref="file"/> >>>> <cache name="clustered" passivation-store-ref="cluster"/> >>>> </caches> >>>> >>>> In other words the passivation-disabled-cache-ref will always be set on AS 8, and there is no default/assumed 'value that can be used to determine to reject on AS7.x. I'm not familiar with this part of the EJB 3.2 spec https://github.com/jaikiran/jboss-as/commit/3fe390d39256eeac06c682ef8ea06... so I don't know how the passivation is turned off for individual beans in an actual deployment. It sort of looks to me as if anybody tries to deploy beans using this new functionality to a server group containing 7.x slaves that the actual deployment should be rejected rather than handled at the subsystem model level? I don't think we have anything in place to inspect deployments on the DC before sending to the slaves, AFAICR we just store the deployments in the repository and submit that data when a slave requests it following a deployment to its server group. I am not sure if it fail on the slave if attempted used? This will probably affect other new features in ! t! > h! >> e EE 7 spe >> c which are not handled by EE 6/AS 7.x as well. >>>> On 5 Mar 2013, at 15:21, Brian Stansberry wrote: >>>> >>>>> On 3/5/13 9:14 AM, Jaikiran Pai wrote: >>>>>> On Tuesday 05 March 2013 08:24 PM, Kabir Khan wrote: >>>>>>> On 5 Mar 2013, at 14:23, Jaikiran Pai wrote: >>>>>>> >>>>>>>> I've been trying to implement a new feature which requires the addition >>>>>>>> of a new model attribute for the EJB3 subsystem root resource. This >>>>>>>> model attribute is supposed to be "mandatory" (i.e. non-nullable at >>>>>>>> model level and "required" at xml level). All works fine without >>>>>>>> bringing into picture older versions of the model. Now while testing >>>>>>>> with older versions of the model and compatibility, things start failing >>>>>>>> for obvious reasons- the older model handlers, parsers etc... have no >>>>>>>> clue about this new attribute. I'm aware that that's where the >>>>>>> The old parsers should make it possible to construct the current model. Is the new attribute something which is now configurable, so you have two choices whereas previously one of those choices was assumed? In that case I think the old parser should create the resulting operation with the assumed default. >>>>>> The new (xml and model) attribute that I'm introducing is for EJB 3.2 >>>>>> spec support. This attribute had no semantics in the previous model >>>>>> versions. So this is a completely new one in terms of semantics. >>>>>> >>>>>>>> subsystems and resources introducing a new attribute in the >>>>>>>> higher model would expect that that attribute to be ignored (I'm not >>>>>>>> using the term discarded or rejected because I am not 100% sure I >>>>>>>> understand the difference yet :) ) by lower versions of the model. >>>>>>> discard = silently discard the attribute >>>>>>> reject = if the attribute is used/does not have some value/is defined/other conditions the transformation should fail >>>>>>> >>>>>>> Normally we prefer reject. So for your case, again assuming that the added attribute has some assumed value in the old version, you should fail transformation if the current model does not have that assumed value. >>>>>> Sorry, my initial mail didn't have the attribute specifics. This new >>>>>> attribute is a EJB 3.2 specific thing so I think "discard" would be >>>>>> applicable in this case. >>>>>> >>>>> Probably not. >>>>> >>>>> The cardinal rule is, the servers running on the legacy version must run >>>>> consistently with other servers running the new version. If they cannot >>>>> (because they don't understand some new piece of config), a reject is >>>>> necessary, and the legacy servers must ignore the profile. >>>>> >>>>> The goal is not to hide unresolvable configuration incompatibilities. >>>>> >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> Principal Software Engineer >>>>> JBoss by Red Hat >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> --------------------------------------- >>>> Kabir Khan >>>> Prinicipal Software Engineer >>>> JBoss by Red Hat >>>> >>> --------------------------------------- >>> Kabir Khan >>> Prinicipal Software Engineer >>> JBoss by Red Hat >>> > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >