Ugh, I am having more toruble with this than I thought I would. Since the
problem of prvidign a UserTransaction to clients running in jBoss that are NOT
beans (i.e., Tomcat servlets) is a harder thing to do, I decided to attack it
first. The problem I am running into is weird...I created two new classses
under org/jboss/tm, UserTransactionFactory and UserTransImpl. As you might
guess, UserTransactionFactory is an ObjectFactory that creates UserTransImpl
objects. Again, I could not use the EnterpriseContext's getTransactionFactory,
because I am trying to serve up UserTransaction's to ALL clients running in our
VM.
The problem is, whenever I try to create a UserTransImpl object I get a
NoClassDefFound exception. This appears regardless of where/when I try to
actually create it (at the time of the TransactionManagerService initialization,
when it is actually looked up, etc.). I checked and that class is DEFINITELY in
the jboss.jar file. Any ideas?
-Charles
marc fleury wrote:
> NamingServer and naming package under jboss
>
> marc
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Crain
> > Sent: Friday, September 15, 2000 8:41 PM
> > To: jBoss Developer
> > Subject: Re: [jBoss-Dev] UserTransaction
> >
> >
> > Speaking of the <cough>messy</cough> jnp code, where is it? I
> > dont think there
> > is an org/jnp dir with the jBoss CVS snapshot I downloaded. Is
> > it perchance
> > documented at all? The problem is that whenever the code starts
> > using stuff
> > imported from org.jnp, it is all guesswork on my part.
> >
> > At any rate, I have some ideas. I will try to do some screwing
> > around this
> > weekend (in-laws are over so you never know).
> >
> > -Charles
> >
> > marc fleury wrote:
> >
> > > wow, not bad for a "first timer".
> > >
> > > You miss the first part but for the rest you are right. Listen
> > Sebastien
> > > and I are almost done, we have the solution and it is indeed with a
> > > TxInterceptorCMT/BMT that get assembled differently so (of
> > course) it fits
> > > in the current model since all the "interceptor" layout really
> > specifies is
> > > that "thou shall invoke stuff in line"... yes...well yes... :))
> > >
> > > Ok seriously now. I am getting more and more warm to the usage of the
> > > try{} finally{} pattern in the interceptors since one is the
> > "going in" and
> > > the other one is "before returning", and as a proof you will
> > see that our
> > > "finally" DOES MOST THE CODE in the CMT stuff. I find that very
> > > interesting.
> > >
> > > Ok we are almost there and we will try to post by tonight, if
> > we can, if not
> > > monday. (Actually we will finish on Monday)
> > >
> > > Since you seem to be a "stellar" contributor in the making (yes I know,
> > > pressure ;-) I would encourage you to tackle the java: stuff it
> > is brainy
> > > and *I* was never able to understand fully the JNP code
> > > (<cough>messy</cough> ;-). For the order of interceptors it is
> > done in the
> > > "container factory" but you don't have to worry about we got it solved.
> > >
> > > regards
> > >
> > > amrc
> > >
> > > > -----Original Message-----
> > > > From: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Crain
> > > > Sent: Friday, September 15, 2000 3:45 PM
> > > > To: jBoss Developer
> > > > Subject: Re: [jBoss-Dev] UserTransaction
> > > >
> > > >
> > > > Wow, nasty. As I understand it, the problem is that you need
> > to go thru
> > > > txAcquisition BEFORE txInterceptor because if a BMT transaction
> > > > is in place, you
> > > > want to acquire it before you use txInterceptor to check the
> > transaction
> > > > attributes for CMT. HOWEVER, you need txInterceptor BEFORE
> > > > txAcquisition so
> > > > txInterceptor can set up a transaction that will be acquired by
> > > > txAcquisition,
> > > > hence the chicken and egg problem.
> > > >
> > > > If I were more familiar with the code, I'd offer some advice.
> > > > I'll take a look
> > > > at it tonight as well and see what I can come up with. I like
> > > > the way you guys
> > > > set up the interceptor system a whole lot...good OO design and
> > > > allows different
> > > > objects to be responsible for different actions in the method
> > invocation
> > > > "pipeline." It's a very flexible system and I think you guys
> > > > will be able to
> > > > come up with a solution that fits within the current model.
> > I'll provide
> > > > whatever help I can...first I have to familiarize myself with how the
> > > > Interceptors get assembled.
> > > >
> > > > I definitely think you are on the right track, thinking that the
> > > > Interceptor
> > > > chain should be assembled differently in the case of BMT. Again
> > > > not knowing the
> > > > assembly process, I don't know how easy this is.
> > > >
> > > > If you guys can work on this, that will lay the groundwork for the
> > > > java:/comp/UserTransaction thing. If I can get enough time this
> > > > weekend, I will
> > > > try to implement it in parallel. Keep me posted on what is happening.
>
> > > >
> > > > -Charles
> > > >
> > > > marc fleury wrote:
> > > >
> > > > > OK
> > > > >
> > > > > 1- yes the tx view to Tomcat is important and a proper
> > implementation of
> > > > > java: is the way to go
> > > > > 2- for the container we have a big problem
> > > > >
> > > > > It turns out that none of the Bean Managed Transaction was
> > > > really taken into
> > > > > account at design time. It reads like this. BMT needs to have
> > > > the instance
> > > > > and more precisely the context in order to make the right
> > > > decision on the Tx
> > > > > management.
> > > > > Now the InstanceAcquisition also needs the Tx to retrieve
> > an instance
> > > > >
> > > > > however: right now the stack of interceptor goes
> > > > > txInterceptor -> txAcquisition
> > > > > when we need
> > > > > txAcquisition -> txInterceptor
> > > > >
> > > > > so, with a chicken and egg problem... we are
> > > > >
> > > > > fucked
> > > > >
> > > > > Sometimes modular stuff has its limits... there might be a
> > > > solution in that
> > > > > we need to actually reimplement a BMTTxInterceptor and not set the
> > > > > TxInterceptor for SessionBeans that work with BMT, change
> > the order of
> > > > > interceptors for these puppies and make sure the spec is met...
> > > > more work
> > > > > than we thought (as usual). This is a design flaw but it is
> > > > good that we
> > > > > are testing the current design now as opposed to down the road.
> > > > Sebastien
> > > > > and I are going to take a stab at it in pure XP style and see
> > > > if we can come
> > > > > up with something by tonight.
> > > > >
> > > > > wish us good luck, this is not looking easy :(
> > > > >
> > > > > marc
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [EMAIL PROTECTED]
> > > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Crain
> > > > > > Sent: Friday, September 15, 2000 1:07 PM
> > > > > > To: [EMAIL PROTECTED]
> > > > > > Subject: [jBoss-Dev] UserTransaction
> > > > > >
> > > > > >
> > > > > > I'm moving this message thread here, because we are
> > getting off topic
> > > > > > for the use group.
> > > > > >
> > > > > > Sebastien, your measure sounds great, and may be
> > sufficient to go the
> > > > > > distance. The only concern I had is that I'd like to see one
> > > > be able to
> > > > > > look up a UserTransaction object OUTSIDE a bean, perhaps
> > from within a
> > > > > > Tomcat servlet running in the jBoss environment. I think
> > > > that would be
> > > > > > very cool, but as we said it requires solving the problem
> > of the java:
> > > > > > namespace.
> > > > > >
> > > > > > I do think it's probably too much of a pain (at least for now) to
> > > > > > provide a UserTransaction to remote clients (i.e.,
> > clients not running
> > > > > > in the same VM as jBoss).
> > > > > >
> > > > > > I'll fool around tonite and see what I can do.
> > > > > >
> > > > > > -Charles
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> >
> >
> >
