IMHO the fact that the names come out long should not stop you. First, we are talking about something
which will only be used when J2EE comes up short. And furthermore if the issue has been thought
through then it should be documented so that when people ask "can you shorten the names" you can
send them a link to the explanation, and that's the end of it.
As someone said, "simple things should be easy, hard things should be possible".
Apparently it was this guy who wrote python who said it ...
http://www.trewornan.clara.net/Python.htm
| David Jencks <[EMAIL PROTECTED]>
11/24/2005 12:17 PM
|
To: user@geronimo.apache.org cc: Subject: Re: Enlisting XAResource objects |
On Nov 24, 2005, at 11:42 AM, [EMAIL PROTECTED] wrote:
>
> It's a singleton. It's not in JNDI.
>
> I understand how you are using JNDI. I am glad you stick to the spec.
>
> As far as providing a proxy through JNDI I can't imagine that it would
> be too hard:
>
> new InitialContext().lookup("geronimo:/gbeans/<blah>");
>
> What am I missing here?
That would require implementing a reasonable global jndi context, and
it would involve really long gbean names in the jndi lookup string.
We were wondering it there was some way to get them into the
java:comp/env context under a shorter name that you configure in the
plan somehow. Since this is non-portable it's probably a bad idea.
But full gbean names in jndi are really awful. But anything less than
a full gbean name invites name collisions.... so no idea here seems
ideal or even really usable yet. Writing the code is the easy part
here, figuring out what to do the hard part. Right now I think what
you are suggesting is probably the only workable idea.
thanks
david jencks
>
>
>
> David Jencks <[EMAIL PROTECTED]>
>
> 11/24/2005 11:11 AM
> Please respond to user
>
> To: [EMAIL PROTECTED]
> cc:
> Subject: Re: Enlisting XAResource objects
>
>
>
>
> On Nov 24, 2005, at 10:38 AM, [EMAIL PROTECTED] wrote:
>
> >
> > >I was going to mention that :-). You still haven't told me how
> your
> > >(presumably j2ee) application finds the part of the RM to talk
> to.
> > >This could be an important part of the picture :-).
> >
> > Applications invoke our own user-transaction-like class, which keeps
> > track of the change set. So when that happens, if I can find the
> > transaction
> > manager then I can call getTransaction.enlistResource(XAResource).
>
> How does the application get the instance of your class? Or is it a
> static method call? There isn't really any way to bind anything not
> specified in the j2ee spec into the geronimo java:comp/env jndi
> namespace. We've thought about providing a way to get a proxy to any
>
> gbean from jndi but it isn't very clear how to fit this into the j2ee
>
> requirements/plans.
> >
> > It looks like any gbean can use the kernel (or some other object, I
> > can't remember) to invoke any method on any other gbean, so I can do
> > that too. Although I am going to write a gbean to emulate a startup
> > class so I can also use a reference.
> >
> > Thanks a lot for the detailed description of how to write a
> > recoverable
> > resource manager. I just realized that since my cache has no
> persistent
> > state independent of the db, so I don't need recovery.
> :-)
> >
> > If I did want to get list under the "ResourceManagers" collection I
>
> > would
> > have to change the j2ee-server plan, whereas I would prefer to use
> an
> > official
> > plan. However, you could add a line in a future release for RMs
> which
> > are
> > not JCA-based:
> >
> > <references name="ResourceManagers">
> >
> > <pattern><gbean-name>geronimo.server:
> > j2eeType=JCAManagedConnectionFactory,*</gbean-name></pattern>
> >
> >
> <pattern><gbean-name>geronimo.server:j2eeType=ActivationSpec,*</gbean-
> > name></pattern>
> >
> > <pattern><gbean-name> <!-- pattern for other third-party > RMs > --> </gbean-name></pattern>
> >
> > </references>
>
> We might add the ability to override reference patterns in the
> config.xml. I was thinking you could lie and give your gbean a
> j2eeType=JCAManagedConnectionFactory :-)
>
> thanks
> david jencks
>
> >
> > *****************************************************************
> > <<>>
> >
> > In compliance with applicable rules and regulations, Instinet
> > reviews and archives incoming and outgoing email communications,
> > copies of which may be produced at the request of regulators.
> > This message is intended only for the personal and confidential
> > use of the recipients named above. If the reader of this email
> > is not the intended recipient, you have received this email in
> > error and any review, dissemination, distribution or copying is
> > strictly prohibited. If you have received this email in error,
> > please notify the sender immediately by return email and
> > permanently delete the copy you received.
> >
> > Instinet accepts no liability for any content contained in the
> > email, or any errors or omissions arising as a result of email
> > transmission. Any opinions contained in this email constitute
> > the sender's best judgment at this time and are subject to change
> > without notice. Instinet does not make recommendations of a
> > particular security and the information contained in this email
> > should not be considered as a recommendation, an offer or a
> > solicitation of an offer to buy and sell securities.
> >
> > *****************************************************************
>
>
>
*****************************************************************
<<
In compliance with applicable rules and regulations, Instinet
reviews and archives incoming and outgoing email communications,
copies of which may be produced at the request of regulators.
This message is intended only for the personal and confidential
use of the recipients named above. If the reader of this email
is not the intended recipient, you have received this email in
error and any review, dissemination, distribution or copying is
strictly prohibited. If you have received this email in error,
please notify the sender immediately by return email and
permanently delete the copy you received.
Instinet accepts no liability for any content contained in the
email, or any errors or omissions arising as a result of email
transmission. Any opinions contained in this email constitute
the sender's best judgment at this time and are subject to change
without notice. Instinet does not make recommendations of a
particular security and the information contained in this email
should not be considered as a recommendation, an offer or a
solicitation of an offer to buy and sell securities.
*****************************************************************
