james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject RE: [RESULT] [VOTE] POJO pattern
Date Wed, 13 Apr 2005 18:51:17 GMT
Stefano Bagnara wrote:
> > The reason I have an issue with this is that as I, and
> > others, have previously highlighted you cannot simply extend
> > an SDI class to implement a CDI equivalent. Java does not
> > allow us to reduce the visibility of the inherited SDI setter
> > methods, but we need to to make the contract of the CDI class
> > clear.
> What does a public setter break in the contract with a CDI
> environment?

CDI's contract is that valid initial states are guaranteed by invocation of
a public constructor. Somewhere in the documentation of an SDI class we
hopefully will find a defintion of which of the possibly many setter methods
must be set in what order to achieve the same valid intial state that CDI
succintly defines in code.

A public setter method on a CDI component is performing a change from the
initial valid state, whereas with SDI it may be doing this or playing a role
in establishing the valid intial state. These are different contracts.

With SDI we need to expose setter methods playing both roles as public.

With CDI we only want to expose the subset of the setter methods that an SDI
class exposes, those that perform a valid state change after the valid
intial state has been established. The rest should be protected.

-- Steve

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message