Chris,
The other area of porting issue to consider is CMP. If you are only
concerned with porting between these two environments that is one thing. If
you want to be able to port to more EJB servers, you might want to stick
with BMP for now. There is a bunch on this in the archives...
You may find other small API differences in different servers, but JDBC
connections and transaction handle acquisition are likely the biggies. As a
matter of style I prefer to use interfaces and factory pattern to handle
this sort of scenario. The interfaces would provide getTransaction(...) and
getConnection(...) semantics. The factory would instantiate the right
wrapper depending on the EJB server. Using Class.forName(...) to get the
right factory would be fine. The name can be in JNDI or an environment
variable.
In general I recommend using abstract super classes when there is common
behavior framework that we want all implementors of the framework to use.
Not when we mearly need different implementations of the same interface. No
need for implementation inheritence in your case.
For what it is worth, we have had good success porting EJB applications from
various other EJB app servers to GemStone/J. The biggest difference is the
way you create deployment descriptors, and this is rectified for the most
part when everyone uses the new XML spec in EJB 1.1.
Regards,
-Chris R.
> -----Original Message-----
> From: chris humphrey [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, November 10, 1999 8:17 PM
> To: [EMAIL PROTECTED]
> Subject: compatability problems
>
> Hi all,
>
> We are currently creating an ejb solution. It is in the works for buying
> a weblogic license, but we dont have it yet. Since we have to deliver
> very soon we built the ejb code using the jonas(bull) app server. We
> have been trying to keep any jonas code separate so it could be removed
> easily. We would really like to be able to switch between the app
> servers without changing code, classpath changes would be ok. We are
> wondering if anyone else has solved this problem and how they solved it.
>
> As I see it, there are 2 differences (at least in my java code so far)
> between weblogic and jonas.
> 1) transactions (can someone tell me which is the standard?)
> - jonas uses 'javax.transaction.UserTransaction'
> - weblogic uses 'javax.jts.UserTransaction'
>
> 2) DataSource,
> - jonas uses JNDI storing a 'javax.sql.DataSource' bound to the db
> pool name .
> - weblogic uses the environment to get to the connection pool.
>
> These are the differences I have come across so far in the dozen plus
> ejb's I have created so far using both environments for this
> application.
>
> One way we have thought to seperate them was to create an abstract
> transaction (and datasource) class. Then store the name in JNDI (or in
> the environment) do a class.forName on the object, and have a reference
> to the abstract class. Then the implementation for each would be
> seperate and we would have the different names in the environment. We
> could also bind the object in JNDI, which would do the same thing.
>
> We am interested in any ways some of you may have solved this problems,
> and any ideas anyone has to solve it.
>
> Thanks in advance
> Chris
>
> Qwest communications
>
> ==========================================================================
> =
> 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".
===========================================================================
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".
