On 9/20/07, David Jencks <[EMAIL PROTECTED]> wrote: <snip> > > > > I guess, in this case, I was expecting to see "jca/svConnector1" in > > the JNDI tree of the server. Simply because I didn't see anywhere > > else I was supposed to declare the JNDI address of the > > ConnectionFactory. > > Geronimo doesn't rely on global jndi for much of anything. In > particular connectors aren't bound into global jndi by default. A > javaee component only gets jndi access to a connection factory by a > having a resource-ref in its spec dd (or an equivalent annotation). > My current problem is that I have an existing set of TestNG test cases, which were developed against another container. These test cases just create an InitialContext instance and use a jndi address to receive the JCA connection pool, against which it can run its tests. These tests aren't in an EJB application, I've just started the JVM with all the appropriate system variables so that the remote container's context can be found. I had problems working out in TestNG how to execute the named tests within a deployed EJB application.
So, I understand that this is my problem, not Geronimo's. :) I see why Geronimo doesn't by default provide a global address for these. I just need to figure out how to work my test cases into the mix. > > > > What I'm trying to do is this. I have written an Inbound Adapters > > that, when its endpoint is being registered, will get a Connection > > using a JNDI address defined as part of it's ActivationSpec. This > > connection will be used to handler incoming events. > > So, I think you can make this work in geronimo but I'm not sure this > is an ideal architecture unless you have a rather unusual EIS. Most > inbound adapters need a connection their entire life, not > intermittently. So there isn't a whole lot of point in getting the > connection from the connection pool, since it isn't going to be > reused by other clients- you mostly risk contention between inbound > and outbound work. Instead you might consider distributing the > configurable properties between the ResourceAdapter, the MCF, and the > activation spec so the inbound adapter has enough information > directly to create the connection from the resource adapter instance > and activation spec properties without the overhead of getting a > connection from a pool. Among other things this might simplify > configuration of your adapter for those who e.g. only want to use it > inbound -- they won't need to set up a pool of outbound connections > that they aren't going to use themselves. Yea, I think you're right. I'd be duplicating the available properties on the ActivationSpec, but it probably makes more sense to do it that ways. As long as I only need to duplicate the mandatory properties... :) > > > > > So, in the scope of the jca-plan.xml file, is this two > > <resourceadapter> nodes: one for the connection pool (containing the > > <outbound-resourceadapter> element), and a second for the > > <resourceadapter-instance> (which contains the JNDI address of the > > first entry in the plan). > > > > Or can this be described using a single <resourceadapter> node? > > You only need one resource adapter instance AFAICT. The activation > spec is configured with the MDB using the inbound adapter. > > Since geronimo doesn't use global jndi for any of this, you have to > get the connection factory your inbound adapter needs available to it > by using a resource-ref in the mdb that will be receiving inbound calls. > > So if you have a resource-ref for your mdb that starts out > > <resource-ref> > <resource-ref-name>jca/SVConnector1</resource-ref-name> > ... > > the activation spec jndi property would be java:comp/env/jca/ > SVConnector1 > > As long as you include the rar configuration as a dependency of your > application (i.e. the moduleId from your plan appears in the > dependencies in the environment element of the application plan) you > shouldn't need any more configuration for geronimo to be able to find > the right connection factory. > Yes, I have a demo MDB application which tests the inbound events (the aforementioned test cases focus on outbound conenctions). I will focus on that for now. > > > > Less importantly, are there any plans to make this a little easier via > > the Admin Console? I don't want to whine. But I can, if you like... > > :) > > What would you like to see? Some way of configuring all the > properties on the resource adapter and MCF instances? That would be > nice but I'm not sure anyone is panting to work on it soon. Maybe a > more realistic near term goal would be some instructions on the > wiki... You are very welcome to contribute :-) > I'd like to see the ability to defined JCA resources in the same manner as JDBC resources. I accept that my prioirities are not everyone else's, so that's all good too. If I get the go ahead to spend some time, I'd be happy to contribute what I can. If nothing else, I would like to contribute to the Wiki, as one of my frustrations have been the sparse doco on this specific topic. Please do not include the responses I have been receiving from this mailing list. This has been extremely helpful in herding me in the right direction. Thanks for the help, Ed
