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.
