----- Original Message -----
From: Jeff Prickett <[EMAIL PROTECTED]>
To: Turbine <[EMAIL PROTECTED]>
Sent: Friday, December 17, 1999 2:32 PM
Subject: Re: Accessing private member data in JDK1.2
<snip>
> >i have been kickin' around the idea of just making it understood that any
> >descendant classes of PersistenceObject must conform to the JavaBean
spec.
> >so that if there is an object attribute that needs to be persistent, say
> >like employeeId, there must be a corresponding method name
setEmployeeId(int
> >idArg). What do you think???
> >
>
> +1 on bean type conventions for JDK117. AFAIK There really is no way to
> disable
> permission checks on JDK117. After looking at the options, using a bean
type
> convention and reflection classes to call the getters/setters works for
me.
> Although I think we should abandon this approach as soon as we abandon the
> JDK117 platform. See the caveat...
>
> Caveat
> -1 on security for that too.
> Anybody can get or set your data.
>
> -1 maintainability
> Anyone can set your data. The great thing about having permissions is you
> can limit where bugs creep in. Private access - we know the bug is
somewhere
> in this class. Protected we know it is in this class or a subclass.
> Package etc...
>
it was a mistake of me to state the "setEmployeeId(intidArg)" what i really
ment was use getEmployeeId() to get the privite/protected attributes of a
PersistentObject/bean. As for the setter methods, this is entirely up to the
application programmer; it is where s/he will enforce the "business rules"
of setting values on the business object. afa i'm conserned the setter
methds do not even have to conform the JavaBean nameing convention, i just
care about having the correct getter methods so that i can dig out the
attribute values when needed.
> "...Limiting access to who manipulates it can help us protect that
data...."
correct but again, this is controlled by the appication programmer and how
s/he choses to implement the setter method of the PersistentObject.
> I would be willing to write all code for this over the weekend, both for
> JDK117 and Java 1.2. I will write the code to collect the data over the
> weekend.
go for it... but keep a look out for changes in the package struture... i
will be changing it over the weekend.
> We will probably need further discussion on tying this code back
> into the class maps and then into actual SQL.
not a problem... it took me over a year of working with this design before i
fully understood how the ClassMap class hierarchy works, so any questions
you have about it just ask away.
-scott-
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
