See below for specific responses.
I've just completed evaluating several O/R mapping tools including TOPLink for Java.
I agree that there are several restrictions, however, I believe they are small in
comparison to the value it adds. I have not utilized TOPLink for WebLogic, but it's
probably the best way to go, by utilizing CMP. As I understand it, TOPLink becomes
replaces WebLogic's container mechanism, and you can utilize TOPLink O/R Mapping tools
on the back-end. See below for specific possibilities to your limitations.
The problem I'm having is in trying to integrate TOPLink for Java (NOT WebLogic
version) with an EJB solution. I've run into a small stumbling block, which is
defining how to best utilize BMP EntityBeans with TOPLink for Java.
I've defined a strategy where I encapsulate the TOPLink ServerSession object in a RMI
object (the Server), and TOPLink ClientSession's and UnitOfWork objects in a bean
called ClientSessionBean. The idea is that every client will have an associated
ClientSessionBean
However, in the BMP methods of an EntityBean, the EntityBean must have the ability to
lookup and identify which client is calling in order to forward the request to the
appropriate ClientSessionBean. JONAS getCallerIdentity() is not implemented, so it
poses some challenges (namely adding some functionality to JONAS).
On Fri, 3 Sep 1999 10:26:13 -0500, Volkmann, Mark <[EMAIL PROTECTED]> wrote:
>I've seen several messages discussing TOPLink on this list. I've been
>evaluating it lately and have identified a number of restrictions it imposes
>on the way your Java classes must be coded. I'm interested in hearing
>whether others have run into these same restrictions. Am I off base on any
>of these?
>
>1) All object fields that are mapped to a database table column must either
>be public or have both get and set methods that are public. There are many
>cases when a class wishes to provide a get method but no set method because
>the field is read-only.
>
This is true, because TOPLink requires the set method to set the attribute when
constructing the object. The solution I used was that TOPLink is mapped to the Bean
class and not the interface. Therefore, you do not need to expose the set methods in
the interface and can still use private attributes with mutator methods in the bean
for TOPLink.
>2) Methods that provide access to collections must return the collection
>object (ex. a Vector) instead of an object such as an Enumeration of
>Iterator. There are many cases when a class doesn't want to do this because
>it doesn't want to allow callers to modify the collection.
>
True, the methods must return collection objects. However, by simply developing your
finder methods to return an Enumeration and return the Collection.elements() method.
i.e.
Enumeration findFooByName( String Name )
{
Vector foos = (Vector)session.executeQuery( "select ..." );
return foos.elements();
}
>3) Every class on the "many end" of a one-to-many relationship must have a
>field that holds a reference back to the "one end". There are many cases
>when it is unnatural for that class to have knowledge of the other class.
>Even worse, if a class can be referenced by collections in multiple other
>classes, it must hold a reference back to each of them.
>
This is a referential integrity issue. By definition, if your foreign keys are
defined, there is a bi-directional relationship.
I'm not sure, but I believe you CAN define a one-to-many relationship without a
reference back to the parent in TOPLink using Queries. You could always write a
finder method which returns the results of a query and not use a mapping relationship,
of course.
>4) When using JDK 1.1, only Vector is supported for one-to-many mappings,
>not Hashtable. JDK 1.2 must be used to utilize Hashtable and other
>collection classes.
>
Somewhere on this board, I read a discussion of the reasons "WHY" this is true, but I
do believe this is a limitation.
>--
> __ __
>/ \/ \ Object Computing, Inc.
>\ / ark (314)589-1617 pager
> \ / (314)955-8087 A.G.Edwards
> \ / olkmann [EMAIL PROTECTED]
> \/
>
===========================================================================
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".
