geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Q: MDB Application cannot find Interface defined in RAR file
Date Wed, 03 Oct 2007 06:23:02 GMT
Lets start small and try to figure out why the message listener class  
isn't getting found.  I have a hard time believing that the rar  
processing is at fault because some of the tranql rars have 2 jars in  
them.... but maybe something else is triggering a bug.

Could you try putting all the connector jars in the geronimo repo and  
adding them to the geroniimo-ra.xml plan?  At that point you ought to  
be able to use the console to try to load the message listener class  
in the rar configuration classloader.

Also, if you have copied any of  the connector classes into  the ejb  
app or included anything in any of the manifest claspaths I advise  
taking them out.  It shouldn't make a difference but....

david jencks
On Oct 2, 2007, at 10:15 PM, Ed Hillmann wrote:

> On 10/3/07, David Jencks <> 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
> ( 
> 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

View raw message