On 10/3/07, David Jencks <[EMAIL PROTECTED]> wrote: > Hi Ed, > > I'm sorry you've been having such a hard time getting this to work.
You and me both. :) > Email is not always the most efficient form for dialog :-). If you > can get on IRC sometime when I am around I can probably help sort > things out more quickly or if IRC is unavailable to you but you have > some time to work through this more continuously we could try > that.... having a couple days between emails its difficult to > remember exactly what the context of your questions is. Yes, it is not very efficient, especially as I'm sure you're across multiple fires like mine. I do appreciate your efforts. I did try installing an IRC client in order to access the IRC server, but I could not. I assume that I cannot access it from behind my firewall, but I didn't chase this up too much. I'm sure it doesn't help that I'm in a different hemisphere (I'm assuming this, but being in Australia, it's typically a safe assumption :) ) > > One of the things I don't like much about the console deployer is > that it tends to conceal the causes of errors and sometimes the fact > of errors :-). I generally get better feedback from the command line > deployer -- also a transcript shows unambiguously what you tried to do. I have not tried the command-line deployer. Perhaps I should use that from now on. > > I noticed a couple o things in the stuff you sent some of which might > be causing problems. > > 1. There are a lot of jar dependencies in your geronimo plan for the > rar... does this mean all these jars are needed by the rar but are > not included in it? If the jars are included in the rar they should > not be needed as dependencies. Knowing exactly what is in the rar > would be helpful There are three jars that used at various parts of the adapter (the outbound adapter uses one jar, one outbound adapter uses the same as the outbound, a second output adapter uses the other two). They have been set up externally, because I was having problems getting the adapters to find the classes when they were deployed within the RAR. Kinda like what I'm going through now. I didn't mind having them in the lib/ext (or, in Geronimo's case, as source modules) because that's actually a good fit for what we want to do with this. What is in the RAR file is svConnector-api.jar, which contains some classes that implement the InteractionSpec interfaces (used by applications using the output adapter), and an interface that should be implemented by MDB's hosting one of the inbound adapters. svConnector-ra.jar, which contains the JCA implementations. Files in this jar may reference the files in the svConnector-api.jar. the ra.xml file. > > 2. The resource adapter has no outbound connectors and all the > ResourceAdapter properties are set to their defaults from ra.xml.... > this is as intended? Yes. In this particular case, I was trying to write an application that used one of the inbound connectors. I wasn't trying to deploy an application that used all the available adapter types. > > 3. the openejb-jar.xml has a dependency on a rar. That would be a > dependency on a rar that is deployed separately, not the one in the > ear. If this is really the openejb-jar.xml from the ear attempt you > should remove that dependency. I was trying this because I could not deploy the RAR file separately (as mentioned in one of my other threads on this list). I was basing this on the sample MDB application (http://cwiki.apache.org/GMOxDOC20/jms-and-mdb-sample-application.html). In the sample, it looked like the RAR file was deployed as part of the EAR. But, then again, I've been misinterpreting other documents, so why should this be any different. :) My preference would be to have the RAR deployed standalone and not part of the application. > > 4. the resource-link in the mdb config does not appear to be pointing > to the resource adapter you configured in the geronimo- > application.xml.... maybe its pointing to the one in the standalone > rar that the openejb-jar.xml is depending on? IIUC you would want > > <message-driven> > <ejb-name>TreEventBean</ejb-name> > <resource-adapter> > <resource-link>InboundSVEvents</resource-link> > </resource-adapter> > </message-driven> Yes, I caught that after I emailed. But that doesn't seem to be part of the problem. When I changed that to match the connector's resource name, I got the same exception. > > 5. There is no additional configuration of the inbound ra in the > openejb-jar.xml so this must mean that all the necessary properties > (including what the message-listener interface is) is set in the ejb- > jar.xml or in annotations? Yes, the MDB has the annotations that have all the necessary properties. It looks like @MessageDriven( name="TreEventBean", messageListenerInterface=TreEventListener.class, activationConfig={ @ActivationConfigProperty(propertyName="ServerName",propertyValue="wallaby"), @ActivationConfigProperty(propertyName="PortNumber",propertyValue="10551"), @ActivationConfigProperty(propertyName="UserName",propertyValue="tpsysadm"), @ActivationConfigProperty(propertyName="Password",propertyValue="tpsysadm"), @ActivationConfigProperty(propertyName="EventPatterns",propertyValue="myPattern") } ) public class TreEventBean implements TreEventListener { > > BTW standalone should be just about the same as non-standalone except > for needing a dependency from the ejb plan to the rar plan.... but > then, in theory, theory and practice are the same... Well, in practice, I'm getting the same results. :( So I must be doing something wrong in both cases. Thanks, Ed
