>For real world modeling, I don't see how EJB's abstract you away from
>locking in to a persistence layer (dependenat objects and sets), at least
>until the EJB2.0 spec is there.
If you implement your entity beans correctly, there is no reason that
your business logic should need to deal with code particular to the
persistence mechanism, they should only work with entity beans as objects.
That is whay I mean by encapsulating the persistence mechanism.
>I've implemented my BMP EJB's using a JDO type persistence layer we wrote,
>which combines the JDO spec from the ODMG (same as Castor) but have
>implemented a few other bits like JDBC interceptors for injecting caching
>pools (or not) as well as using the ideas in Connectors for security
>interceptor injections (for using Oracle's FGAC, or using the security from
>things like Peoplesoft).
This sounds amazing! Is there anyway I can learn more about his, or is this
all highly proprietary. :)
>I was quite juiced on this until ... I saw the the JDO, EJB2.0 and JMS
query
>styles ... all of which are different. Why is that?
Yes it is kind of dumb, but I would choose JDO query style, since it is
based on java syntax, and more familiar to the average developer.
>I also very much dislike the post processing being touted for JDO as you
>need to do a bunch of Magic to get around classloader security, etc. I
much
>prefer the straightforward style of JDO as available by most OODB vendors.
Post processing is a lot better than hundred line deployment
descriptors. :)
Floyd Marinescu
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
