You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Laird Nelson <lj...@gmail.com> on 2010/06/20 22:09:20 UTC

Latest 3.1.3 SNAPSHOT can't read ra.xml anymore?

You'll forgive me; I'm trying to integrate about three different open source
packages and they're all breaking in different ways :-) so I think I've
assigned the error to the responsible parties, but I might have slipped up.

I have a resource adapter for Drools that I've written.

It worked fine yesterday.

Today I upgraded it to Drools v5.1.0.M2, which required some Java API
changes.  I did not touch the ra.xml file.

The whole thing is tested under OpenEJB 3.1.3-SNAPSHOT--I fire up a
@LocalClient with an injected @Resource and verify both that my .rar is
working and that a container can inject it.

This morning, I began getting the following error.  I suppose that it's
probably due to a 3.1.3-SNAPSHOT build that somehow changed dramatically in
this area.  The error is triggered by the lookup in the InitialContext, but
it's really rooted in the DeploymentLoader code.  Perhaps something changed
there?

Any help is appreciated before I file a regression bug.

Here's the stack:

org.apache.openejb.OpenEJBException: Cannot unmarshall the ra.xml file:
file:/Users/ljnelson/Projects/foobar/foobar-drools-jca/target/classes/META-INF/ra.xml:
The property has a getter "public java.util.List
org.apache.openejb.jee.ResourceAdapter.getConfigProperty()" but no setter.
For unmarshalling, please define setters. (Or if this is a collection
property, make sure that the getter returns a collection instance.)
    at
org.apache.openejb.config.ReadDescriptors.readConnector(ReadDescriptors.java:437)
    at
org.apache.openejb.config.DeploymentLoader.createConnectorModule(DeploymentLoader.java:916)
    at
org.apache.openejb.config.DeploymentLoader.load(DeploymentLoader.java:155)
    at
org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:520)
    at
org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguration(ConfigurationFactory.java:391)
    at
org.apache.openejb.assembler.classic.Assembler.getOpenEjbConfiguration(Assembler.java:300)
    at
org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
    at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:125)
    at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:60)
    at org.apache.openejb.OpenEJB.init(OpenEJB.java:271)
    at org.apache.openejb.OpenEJB.init(OpenEJB.java:250)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at
org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36)
    at
org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
    at
org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
    at
org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
    at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
    at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
    at javax.naming.InitialContext.init(InitialContext.java:223)
    at javax.naming.InitialContext.<init>(InitialContext.java:197)
    at
com.foobar.drools.jca.TestCaseIntegrateWithOpenEJB.setUp(TestCaseIntegrateWithOpenEJB.java:105)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
    at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
    at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
    at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
    at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
    at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
    at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
    at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
    at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115)
    at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:140)
    at org.apache.maven.surefire.Surefire.run(Surefire.java:109)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
    at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1017)

And here's my (sanitized) ra.xml (which many of you will remember from my
hacking several months ago):

<?xml version="1.0" encoding="UTF-8"?>
<!--

This ra.xml file is actually ONLY USED DURING UNIT TESTING.  The reason it
is not included in src/test/resources/META-INF instead is due to an OpenEJB
issue.  Briefly, src/test/resources/META-INF must contain an empty
ejb-jar.xml for OpenEJB to run the unit tests appropriately.  If such a file
exists, an ra.xml file cannot also exist there, since OpenEJB will not be
able to deploy the resource adapter it represents.  Consequently, we produce
this ra.xml as a "main" resource, not a "test" resource, so that OpenEJB
finds both the resource adapter and the @LocalClient.

If this is confusing, see
http://openejb.apache.org/3.0/local-client-injection.html, and understand
that once an ejb-jar.xml is found in a META-INF directory on the classpath,
that particular META-INF directory is not scanned for any other deployment
descriptor.

-->
<connector xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/connector_1_5.xsd" version="1.5">
  <description>A ResourceAdapter for the Drools rules engine.</description>
  <display-name>Drools ${droolsVersion} ResourceAdapter</display-name>
  <vendor-name>Foobar</vendor-name>
  <eis-type>Rules Engine</eis-type>
  <resourceadapter-version>1.0</resourceadapter-version>
  <license>
    <license-required>false</license-required>
  </license>
  <resourceadapter>


<resourceadapter-class>com.foobar.drools.jca.DroolsResourceAdapter</resourceadapter-class>

    <config-property>
      <config-property-name>scanningInterval</config-property-name>
      <config-property-type>java.lang.Integer</config-property-type>
      <config-property-value>20</config-property-value>
    </config-property>

    <config-property>
      <config-property-name>scanResources</config-property-name>
      <config-property-type>java.lang.Boolean</config-property-type>
      <config-property-value>true</config-property-value>
    </config-property>

    <config-property>
      <config-property-name>scanDirectories</config-property-name>
      <config-property-type>java.lang.Boolean</config-property-type>
      <config-property-value>true</config-property-value>
    </config-property>

    <config-property>
      <config-property-name>monitorChangeSetEvents</config-property-name>
      <config-property-type>java.lang.Boolean</config-property-type>
      <config-property-value>true</config-property-value>
    </config-property>

    <config-property>
      <config-property-name>changeSetResourceName</config-property-name>
      <config-property-type>java.lang.String</config-property-type>

<config-property-value>TestCaseDeployment.changeset</config-property-value>
    </config-property>

    <outbound-resourceadapter>

      <connection-definition id="TestConnection">


<managedconnectionfactory-class>com.foobar.drools.jca.DroolsManagedConnectionFactory</managedconnectionfactory-class>


<connectionfactory-interface>org.drools.KnowledgeBase</connectionfactory-interface>


<connectionfactory-impl-class>com.foobar.drools.jca.KnowledgeBaseUserConnectionFactory</connectionfactory-impl-class>


<connection-interface>org.drools.runtime.StatelessKnowledgeSession</connection-interface>

<connection-impl-class>com.foobar.drools.jca.StatelessKnowledgeSessionUserConnection</connection-impl-class>

      </connection-definition>

      <transaction-support>NoTransaction</transaction-support>

      <!-- We actually don't have any way of supporting authentication. -->
      <authentication-mechanism>

<authentication-mechanism-type>BasicPassword</authentication-mechanism-type>

<credential-interface>javax.resource.spi.security.PasswordCredential</credential-interface>
      </authentication-mechanism>
      <!-- Since we don't authenticate at all, we could easily
re-authenticate! -->
      <reauthentication-support>true</reauthentication-support>

    </outbound-resourceadapter>

  </resourceadapter>
</connector>

Best,
Laird

Re: Latest 3.1.3 SNAPSHOT can't read ra.xml anymore?

Posted by Laird Nelson <lj...@gmail.com>.
OK, this is very weird.

David, I'll send you the project to your v i s i email.

Here's the gist: my resource adapter itself--his signature--hasn't changed.

But the various connection factories and whatnot--their signatures have
changed to keep up with the changes in Drools.

So what I've found is:
* My (unchanged) ra.xml works fine when the code behind it is based on
Drools 5.0.1.
* My (unchanged) ra.xml blows up in the way I've described when the code
behind it is based on Drools 5.1.0.M2.
* My (unchanged) ra.xml seems to work fine when the code behind it is based
on Drools 5.1.0.SNAPSHOT, but the test fails for some reason; looks like
Drools has a bad pom in it somewhere.  I love integrating open source
software!  Sigh.

So I'll send you my project with the M2 version.  You should be able to
change M2 to SNAPSHOT to 5.0.1 at your leisure to see what's going on.

Best,
Laird

On Sun, Jun 20, 2010 at 7:47 PM, David Blevins <da...@visi.com>wrote:

>
> On Jun 20, 2010, at 3:37 PM, Laird Nelson wrote:
>
> > Actually I did; read below the stack.
>
> Whoops.  Missed it.  Ok my first attempt was to plug the xml right into our
> xml read/write tests but that resulted in no errors.
>
> Here's that patch if you're interested:  http://gist.github.com/446229
>
> Tried it on both trunk and the 3.1.x branch.
>
> To rule out any stale code issues, I've uploaded new 3.1.3-SNAPSHOT jars to
> the maven repo.
>
> If that doesn't do the trick then we might need a sample project to
> reproduce it.
>
> Thanks for posting this, btw!
>
> -David
>
> > On Sun, Jun 20, 2010 at 6:24 PM, David Blevins <david.blevins@visi.com
> >wrote:
> >
> >>
> >> On Jun 20, 2010, at 1:51 PM, Laird Nelson wrote:
> >>
> >>> On Sun, Jun 20, 2010 at 4:09 PM, Laird Nelson <lj...@gmail.com>
> >> wrote:
> >>>
> >>>> You'll forgive me; I'm trying to integrate about three different open
> >>>> source packages and they're all breaking in different ways :-) so I
> >> think
> >>>> I've assigned the error to the responsible parties, but I might have
> >> slipped
> >>>> up.
> >>>>
> >>>
> >>> I think I slipped up, but it still might be on topic, so bear with me.
> >>>
> >>> I re-ran a version before I made any changes to my code, and the same
> >>> snapshot build of OpenEJB loaded the ra.xml just fine.
> >>>
> >>> So to recap: ra.xml stays the same.  OpenEJB stays the same.  Drools
> >>> Resource Adapter code changes.  Suddenly OpenEJB can't read the ra.xml
> >>> anymore; binding is failing.
> >>>
> >>> This suggests to me that perhaps a bean property mentioned in the
> ra.xml
> >> has
> >>> vanished off my ResourceAdapter, but--in any case--I'm not being told
> >> which
> >>> one it is, and I don't see anything obvious missing.  Certainly the
> >>> signatures of my ResourceAdapter have not changed.
> >>>
> >>> Where...kind of at sea on this one.
> >>
> >> Think I might have some idea what changed.  Is it possible you can post
> >> your ra.xml?
> >>
> >> -David
> >>
> >>
>
>

Re: Latest 3.1.3 SNAPSHOT can't read ra.xml anymore?

Posted by David Blevins <da...@visi.com>.
On Jun 20, 2010, at 3:37 PM, Laird Nelson wrote:

> Actually I did; read below the stack.

Whoops.  Missed it.  Ok my first attempt was to plug the xml right into our xml read/write tests but that resulted in no errors.

Here's that patch if you're interested:  http://gist.github.com/446229

Tried it on both trunk and the 3.1.x branch.

To rule out any stale code issues, I've uploaded new 3.1.3-SNAPSHOT jars to the maven repo.

If that doesn't do the trick then we might need a sample project to reproduce it.

Thanks for posting this, btw!

-David

> On Sun, Jun 20, 2010 at 6:24 PM, David Blevins <da...@visi.com>wrote:
> 
>> 
>> On Jun 20, 2010, at 1:51 PM, Laird Nelson wrote:
>> 
>>> On Sun, Jun 20, 2010 at 4:09 PM, Laird Nelson <lj...@gmail.com>
>> wrote:
>>> 
>>>> You'll forgive me; I'm trying to integrate about three different open
>>>> source packages and they're all breaking in different ways :-) so I
>> think
>>>> I've assigned the error to the responsible parties, but I might have
>> slipped
>>>> up.
>>>> 
>>> 
>>> I think I slipped up, but it still might be on topic, so bear with me.
>>> 
>>> I re-ran a version before I made any changes to my code, and the same
>>> snapshot build of OpenEJB loaded the ra.xml just fine.
>>> 
>>> So to recap: ra.xml stays the same.  OpenEJB stays the same.  Drools
>>> Resource Adapter code changes.  Suddenly OpenEJB can't read the ra.xml
>>> anymore; binding is failing.
>>> 
>>> This suggests to me that perhaps a bean property mentioned in the ra.xml
>> has
>>> vanished off my ResourceAdapter, but--in any case--I'm not being told
>> which
>>> one it is, and I don't see anything obvious missing.  Certainly the
>>> signatures of my ResourceAdapter have not changed.
>>> 
>>> Where...kind of at sea on this one.
>> 
>> Think I might have some idea what changed.  Is it possible you can post
>> your ra.xml?
>> 
>> -David
>> 
>>

Re: Latest 3.1.3 SNAPSHOT can't read ra.xml anymore?

Posted by Laird Nelson <lj...@gmail.com>.
Actually I did; read below the stack.

Best,
Laird

On Sun, Jun 20, 2010 at 6:24 PM, David Blevins <da...@visi.com>wrote:

>
> On Jun 20, 2010, at 1:51 PM, Laird Nelson wrote:
>
> > On Sun, Jun 20, 2010 at 4:09 PM, Laird Nelson <lj...@gmail.com>
> wrote:
> >
> >> You'll forgive me; I'm trying to integrate about three different open
> >> source packages and they're all breaking in different ways :-) so I
> think
> >> I've assigned the error to the responsible parties, but I might have
> slipped
> >> up.
> >>
> >
> > I think I slipped up, but it still might be on topic, so bear with me.
> >
> > I re-ran a version before I made any changes to my code, and the same
> > snapshot build of OpenEJB loaded the ra.xml just fine.
> >
> > So to recap: ra.xml stays the same.  OpenEJB stays the same.  Drools
> > Resource Adapter code changes.  Suddenly OpenEJB can't read the ra.xml
> > anymore; binding is failing.
> >
> > This suggests to me that perhaps a bean property mentioned in the ra.xml
> has
> > vanished off my ResourceAdapter, but--in any case--I'm not being told
> which
> > one it is, and I don't see anything obvious missing.  Certainly the
> > signatures of my ResourceAdapter have not changed.
> >
> > Where...kind of at sea on this one.
>
> Think I might have some idea what changed.  Is it possible you can post
> your ra.xml?
>
> -David
>
>

Re: Latest 3.1.3 SNAPSHOT can't read ra.xml anymore?

Posted by David Blevins <da...@visi.com>.
On Jun 20, 2010, at 1:51 PM, Laird Nelson wrote:

> On Sun, Jun 20, 2010 at 4:09 PM, Laird Nelson <lj...@gmail.com> wrote:
> 
>> You'll forgive me; I'm trying to integrate about three different open
>> source packages and they're all breaking in different ways :-) so I think
>> I've assigned the error to the responsible parties, but I might have slipped
>> up.
>> 
> 
> I think I slipped up, but it still might be on topic, so bear with me.
> 
> I re-ran a version before I made any changes to my code, and the same
> snapshot build of OpenEJB loaded the ra.xml just fine.
> 
> So to recap: ra.xml stays the same.  OpenEJB stays the same.  Drools
> Resource Adapter code changes.  Suddenly OpenEJB can't read the ra.xml
> anymore; binding is failing.
> 
> This suggests to me that perhaps a bean property mentioned in the ra.xml has
> vanished off my ResourceAdapter, but--in any case--I'm not being told which
> one it is, and I don't see anything obvious missing.  Certainly the
> signatures of my ResourceAdapter have not changed.
> 
> Where...kind of at sea on this one.

Think I might have some idea what changed.  Is it possible you can post your ra.xml?

-David

Re: Latest 3.1.3 SNAPSHOT can't read ra.xml anymore?

Posted by Laird Nelson <lj...@gmail.com>.
On Sun, Jun 20, 2010 at 4:09 PM, Laird Nelson <lj...@gmail.com> wrote:

> You'll forgive me; I'm trying to integrate about three different open
> source packages and they're all breaking in different ways :-) so I think
> I've assigned the error to the responsible parties, but I might have slipped
> up.
>

I think I slipped up, but it still might be on topic, so bear with me.

I re-ran a version before I made any changes to my code, and the same
snapshot build of OpenEJB loaded the ra.xml just fine.

So to recap: ra.xml stays the same.  OpenEJB stays the same.  Drools
Resource Adapter code changes.  Suddenly OpenEJB can't read the ra.xml
anymore; binding is failing.

This suggests to me that perhaps a bean property mentioned in the ra.xml has
vanished off my ResourceAdapter, but--in any case--I'm not being told which
one it is, and I don't see anything obvious missing.  Certainly the
signatures of my ResourceAdapter have not changed.

Where...kind of at sea on this one.

Best,
Laird

Re: Latest 3.1.3 SNAPSHOT can't read ra.xml anymore?

Posted by David Blevins <da...@visi.com>.
On Jun 20, 2010, at 1:09 PM, Laird Nelson wrote:

> This ra.xml file is actually ONLY USED DURING UNIT TESTING.  The reason it
> is not included in src/test/resources/META-INF instead is due to an OpenEJB
> issue.  Briefly, src/test/resources/META-INF must contain an empty
> ejb-jar.xml for OpenEJB to run the unit tests appropriately.  If such a file
> exists, an ra.xml file cannot also exist there, since OpenEJB will not be
> able to deploy the resource adapter it represents.  Consequently, we produce
> this ra.xml as a "main" resource, not a "test" resource, so that OpenEJB
> finds both the resource adapter and the @LocalClient.

Side note on this one -- it's always bugged me too.

It's a tiny bit of work but conceptually simple.  90% of the work would be local to the DeploymentLoader class:

  http://svn.apache.org/repos/asf/openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/config/DeploymentLoader.java

Essentially the 'discoverModuleType' method would get reworked to not have return statements and instead add the types to a list and return a list -- renaming that method to 'discoverModuleTypes'.  The 'public AppModule load(File jarFile) throws OpenEJBException' method would be altered to iterate over the list and create modules for each one.  That method already returns an AppModule, so the code downstream of it is already looking at all "standalone" modules (say a single ejb-jar.xml) as ears.  So the rest of the code is essentially already ready for it.


-David