tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laird Nelson <ljnel...@gmail.com>
Subject Latest 3.1.3 SNAPSHOT can't read ra.xml anymore?
Date Sun, 20 Jun 2010 20:09:20 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message