Hi Chris,
Attached please find the super secret PortableContext articles 1 and 2 and the
source code. I give this to you in the hopes that you will give me some feedback
on the PortableContext code.
The first article is a rough draft. The typos and codos were fixed in a
subsequent version, but I don't it on hand. The second article I just finished
writing today so its pretty rough also. Both articles will be published in
JavaWorld. Article 1 will be published this month on the 18th and article 2 will
be published in December about the same time.
The source code has been tested in both J2EE RI and Weblogic 4.5. I'm extremely
interested in your feedback and any problems or enhancements you may discover.
The code is not documented because the article has an extensive examination of
the code and strategies used.
Richard
Chris Raber wrote:
> Richard,
>
> Very nice. Is this solution posted at ejbnow?
>
> Regards,
>
> -Chris.
>
> > -----Original Message-----
> > From: Richard Monson-Haefel [SMTP:[EMAIL PROTECTED]]
> > Sent: Thursday, November 11, 1999 8:07 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: compatability problems
> >
> > Chris,
> >
> > As you know beans developed for EJB 1.0 servers are not forward-compatible
> > with
> > EJB 1.1 servers. In other words, beans developed for EJB 1.0 will not work
> > in
> > EJB 1.1 servers. In your case you are going between JOnAS and Weblogic,
> > but
> > the portability issues are the same: How do you create beans that work in
> > different versions or brands of server?
> >
> > I have developed an abstraction called the PortableContext that address
> > many of
> > the forward compatibility issues when porting beans from EJB 1.0 to EJB
> > 1.1.
> > The PortableContext presents the bean developer with a single interface
> > that
> > hides differences between EJB server versions including security, JDBC
> > connections (DataSource vs simple Connection), EJB references, and
> > properties.
> > It can easily be extended to cover your UserTransaction problem (JTS vs
> > JTA)
> > and already accommodates differences in how JDBC connections are obtained.
> >
> > When the PortableContext is employed, the bean code does not need to
> > change
> > when porting beans to a new server. The PortableContext will
> > automatically
> > change its behavior to work in different EJB servers at runtime.
> >
> > There is a two part article explaining this approach in detail that will
> > be
> > published soon (days) in JavaWorld.
> >
> > Richard
> >
> > --
> > Richard Monson-Haefel
> > EJB Expert for jGuru.com
> > ( http://www.jguru.com )
> >
> > Author of Enterprise JavaBeans
> > Published by O'Reilly & Associates
> > ( http://www.ejbnow.com )
> >
> > chris humphrey wrote:
> >
> > > 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".
>
> ===========================================================================
> 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".
--
Richard Monson-Haefel
EJB Expert for jGuru.com
( http://www.jguru.com )
Author of Enterprise JavaBeans
Published by O'Reilly & Associates
( http://www.ejbnow.com )
portable_context articles.zip
