5:05 p.m.
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