> It looks to me as if having JAWSPersistenceManager get the class of a
> JDBCCommandFactory from the container metadata, and having
> JDBCCommandFactory descendants (and the commands they create)
> implement the
> db specific behaviour is a possibility. Is this what you
> were proposing?
Not exactly. Yes, you're right that if you go for the JDBCCommandFactory
then you're able to provide commands that can implement the database
specific functionality. However, what I propose, is to reuse the existing
commands, because almost the all functionality remains the same.
For example, if I want to override the setParameter(PreparedStatement, int,
int, Object), getResultObject(ResultSet, int, Class) or jdbcExecute(Object)
in the JDBCCommand class (to customize the serialization for example), I can
do this by
public class MyJDBCCommand extends JDBCCommand {
protected void setParameter(...) {...}
protected Object getResultObject(...) {...}
protected jdbcExecute(Object arg) {...}
}
All existing JDBC commands could be reused (the code there is basically
business logic, and not DB specific). But I cannot do this because all of
them are inherited from the JDBCCommand, not MyJDBCCommand.
That is my vision of the problem.
My idea is that all JDBC commands use delegation instead of the inheritence.
Then if I'm able to pass my JDBCCommand class as the parameter, I can reuse
current code and don't worry about the creating a bunch of classes by
copying them from existing code.
Regards,
Roman.
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
