> I do not think this will work because the RDF classes expecting the getUserId()
>method in BaseNewappUserImpl, rather
> than NewappUserImpl. If it does work, then it is cetrainly counter-intuitive and
>difficult to implement. Ultimately I
> think this should have a fairly straightforward solution - it is after all
>supposedly designed with this in mind (isn't
> it?)
I don't believe I had those results.. I think implementing the methods in
NewappUserImpl worked fine for me... I dont remember changing anything in the base
classes... although I'm not in front of the computer with that source...
> A few minutes of investigation has revealed that DBUserManager calls back into
>TurbineUserPeer.buildCriteria() which
> moves from Perm to criteria the columns it knows about and then writes the remaining
>Perm to Objectdata. Given that
> using an alias in the application schema does not generate anything new in terms of
>TurbineUser/TurbineUserPeer, this
> means that the only way to add additional attributes to TurbineUser is to use Perm
>(and thus there is no point adding
> columns to TURBINE_USER in turbine-schema.xml ... given the current design that is.)
Shouldn't it call into NewappUserPeer so you have the opportunity to override/extend
that functionality? Does it not get the Peer to call into from TR.props? I'd answer
these questions myself if I was at a different computer...
</dan>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
