Do you get an error if you don't list any EJBs at all? It looks like
that technically violates the schema, but it's worth a try.
Otherwise, can you post your dummy bean implementation class? Perhaps
it's missing one of the required methods like ejbCreate?
In any case, it would be extremely sensible for us to add an element
to the EAR deployment plan to let you list JARs within the EAR to add
to the EAR class path. David J, what do you think?
Thanks,
Aaron
On 12/11/06, Spotts, Joel (ISS Atlanta) <[EMAIL PROTECTED]> wrote:
Thanks for the suggestion. I am trying that tact, but am now running into
another issue. When I try and create a dummy ejb jar, I get an error when
the ejb module is loaded. I tried googling the exception as well searching
the archives for the exception, but with no success. The exception is as
follows:
14:27:43,483 ERROR [GBeanInstanceState] Error while starting; GBean is now
in the FAILED state:
abstractName="iss/SampleEar/1.0/car?EJBModule=DummyEJB.jar,J2EEApplication=iss/SampleEar/1.0/car,j2eeType=StatelessSessionBean,name=Dummy"
java.lang.IllegalArgumentException: Class class
org.openejb.proxy.SessionEJBLocalHome$$EnhancerByCGLIB$$7bde9985
does not use a MethodInterceptor
at
net.sf.cglib.proxy.MethodProxy.find(MethodProxy.java:129)
at
org.openejb.dispatch.MethodHelper.getSuperIndex(MethodHelper.java:82)
at
org.openejb.proxy.EJBProxyHelper.buildProxyToShadowIndex(EJBProxyHelper.java:122)
at
org.openejb.proxy.EJBProxyHelper.getOperationMap(EJBProxyHelper.java:67)
at
org.openejb.proxy.EJBProxyFactory$InterfaceMaps.createOperationsMap(EJBProxyFactory.java:397)
at
org.openejb.proxy.EJBProxyFactory$InterfaceMaps.<init>(EJBProxyFactory.java:368)
at
org.openejb.proxy.EJBProxyFactory.<init>(EJBProxyFactory.java:88)
at org.openejb.GenericEJBContainer.<init>(GenericEJBContainer.java:172)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at
java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:933)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540)
at
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:374)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:527)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:508)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(<generated>)
at
net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$4ac69885.startConfiguration(<generated>)
at
org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCommand.java:67)
at java.lang.Thread.run(Thread.java:595)
Here is my ejb-jar.xml
<ejb-jar 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/ejb-jar_2_1.xsd";
version="2.1">
<enterprise-beans>
<!-- Session Beans -->
<session >
<description><![CDATA[]]></description>
<ejb-name>Dummy</ejb-name>
<local-home>net.iss.geronimo.ejb.DummyLocalHome</local-home>
<local>net.iss.geronimo.ejb.DummyLocal</local>
<ejb-class>net.iss.geronimo.ejb.DummyBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Bean</transaction-type>
</session>
</enterprise-beans>
<assembly-descriptor >
</assembly-descriptor>
</ejb-jar>
and my openejb-jar.xml
<?xml version="1.0" encoding="UTF-8"?>
<openejb-jar
xmlns="http://www.openejb.org/xml/ns/openejb-jar-2.1";>
<enterprise-beans>
<session>
<ejb-name>Dummy</ejb-name>
</session>
</enterprise-beans>
</openejb-jar>
The actual ejb beans are completely devoid of any content (i.e. all method
implementations are empty, and LocalHome and Local interfaces are declare no
methods). I tried to create as minimal an ejb as possible.
Any ideas?
Thanks,
Yoel Spotts
________________________________
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Friday, December 08, 2006 7:00 PM
To: [email protected]
Subject: Re: Third party jars inside ear files
The only think I know of that you can do is to include a dummy ejb jar file
with no ejbs in it and put your libs in it's manifest classpath. It will
need a skeleton ejb-jar.xml descriptor so it can get deployed correctly.
You are correct that the dependency elements only refer jars outside the ear
in the geronimo repository. The other thing you could do is to put the jars
in the geronimo repo and use dependency elements. This is fairly easy if
you use maven... .but still not as easy as it should be.
hope this helps
david jencks
On Dec 8, 2006, at 12:10 PM, Spotts, Joel ((ISS Atlanta)) wrote:
I have a number of third party jars I want to include inside an ear. I would
like all my web applications to have access those jars. I realize that I can
list those jars inside the manifest files of the wars (using the Class path
directive), but that would mean that each war would load those jars in
different class loaders. Is there a way I can designate that those jars I
include in the ear should be available to the wars loaded by the class
loader of the ear (such that the same class loader would load the jars for
all wars inside that ear)? I have not found a way to configure that in the
geronimo-application.xml. The closest directive I found is the dependency
directive, but it seems like you can only load jars external to the ear
(placed in the repository as separate compenents), but not for jars included
in the ears?
Thanks,
Yoel Spotts
