I know this is not the answer to your question but It might be useful to
evaluate an alternate approach that consists in not writing a
SessionBean for each database, instead I propose you to write a sigle
SessionBean which uses "Adapters" for each DBMS, of course, this assumes
(but not requires) that the SessionBean is stateful.
public class SQLBean implements SessionBean {
private DBAdapter ad;
/**
* Choose a DB on creation time...
*
* @ejb:create-method
*/
public void ejbCreate(String db) {
if(db == "Oracle") {
setAdapter(new OracleAdapter("properties"));
}
}
private void setAdapter(DBAdapter ad) {
this.ad = ad;
}
/**
* This is an example wrapper method, it function
* should be invoking the adapter
* @ejb: interface-method
*/
public java.util.Collection executeSQL(String query) {
if(adapter != null) {
adapter.executeSQL(query);
}
}
}
On the other side the definitions of the interface and the
implementation ....
public interface DBAdapter {
public java.util.Collection executeSQL(String query);
//...
}
public class OracleAdapter implements DBAdapter { ...
And so on...
Regards...
On Wed, 2003-08-06 at 15:44, Marco Tedone wrote:
> Hi, we are developing an unusual applicatoin, basically centered on session
> beans which manage database (not entity beans, because the data to be
> retrieved are dynamic). To make our application multi-database compliant,
> and following a pattern, we defined basically one Session bean for each used
> database (MySQL, Oracle, SQLServer, Postgresql and other could be added).
> The application then choose the right session bean depending on user
> selections and this is possible thanks to a common interface which all the
> database-specific interfaces inherit from. This way a client will have
> simply to get a reference to the super-interface (as the methods are common
> for every session bean) and polymorphism will be guaranteed. So far so good.
> So far we developed the session beans manually but now I would like to
> migrate to XDoclet, even because we are planning to develop other beans, and
> XDoclet will be of great help.
>
> As you will probably guess, our problem is how we could define via XDoclet
> that each database-specific interface will inherit from the common one (now
> is possible because all the interface was declared manually).
>
> Any help will be appreciated.
>
> Marco
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> xdoclet-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/xdoclet-user
--
Eduardo H. Ram�rez Rangel
Centro de Sistemas Inteligentes
5o. Piso Torre Sur CETEC, ITESM Campus Monterrey
(52-81) 8328-4380, 83-58-2000. Ext. 5134
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
