Good thoughts, some comments. :) Our design is actually not the most typical EJB design. Due to a large amount of redundancy in our code, we implemented a single EJB that then calls methods on a specific implementation class depending on the object requested from the Struts tier (sort of like a "controller" of sorts). For example, there are three objects we deal with (these are fabricated for demonstration's sake):
Pencil Pen Crayon To perform SQL operations or some business operation on one of these objects, an EJB is invoked and told what implementation class it should use for doing "something." Thus, all calls to the pencil implementation class really come through the EJB. I'll leave the reasons we did that aside, suffice it to say that we have an EJB that has numerous supporting implementation classes that can be called depending on the incoming request. All [I should say "most"] our SQL is in those specific implementation classes. The requirement is not so much to be able to support a different DBMS, but to be able to customize the SQL without editing a Java file (ie. ultimately "recompilation of code"). I like your idea Joe, and we do have a such a JNDI lookup system in place, but the bottom of your email is the crux of the matter - it's not so much that we care about providing that flexibility to the client, but it has the potential to be *very* convenient for us. :) That is, of course, if it doesn't take us too many hours to implement and then refactor existing code. =p Thanks for the consideration, if there are any additional ideas please shoot them my way, for now it seems I have a lot to consider. :-) -Chris -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
