EJB lookup in JNDI?
Hi Folks, With Gianny's fix for EJB deployment (thanks!) I can now run the deploy tool on modules/j2ee/target/test-ejb-jar.jar and start up the server and everything looks good, i.e. no stack traces. Now I'm trying to call the EJB from a unit test outside Geronimo but I'm stuck looking it up. I cribbed some JNDI parameters from one of the unit tests and I can connect to JNDI but when I list the entries in the context all I find is JMXConnector. I seem to get the same result no matter what I pass to InitialContext.list(). Here are my properties: target name=test-geronimo description=Run the unit tests that depend on the build having been deployed in Geronimo. java classname=skeleton.ServerUnitTest failonerror=true classpathref=testpath sysproperty key=java.naming.factory.initial value=com.sun.jndi.rmi.registry.RegistryContextFactory / sysproperty key=java.naming.factory.url.pkgs value=org.apache.geronimo.naming / sysproperty key=java.naming.provider.url value=rmi://localhost:1099/ /java /target The EJB's entry in openejb-jar.xml is: enterprise-beans session ejb-nameSimpleStatelessSession/ejb-name jndi-nameclient/test/simple/SimpleStatelessSessionHome/jndi-name /session /enterprise-beans I guess I should ask first if this functionality (i.e. remote JNDI and EJB calls) is even implemented, maybe I'm trying something that's not built yet. If it's supposed to work I'd welcome any tips people can offer. Regards, Toby
Re: Testing Maven 1.0 (success on linux/1.4.2)
On Wed, Jul 14, 2004 at 11:32:51AM -0700, Jeremy Boynes wrote: Would appreciate it if people can confirm if geronimo builds on different platforms with the new release of maven 1.0 BUILD SUCCESSFUL on Fedora Core release 2 (Tettnang) java version 1.4.2_04 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)
Re: Testing Maven 1.0
Lynch, Peter wrote: OK, after deleting my maven repository, then figuring out what NTLM authentication was and how to configure it behind my firewall, I finally got... BUILD SUCCESSFUL on Windows NT4 SP6 java version 1.4.2_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02) Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode) Thanks However, I got the following errors: Running org.apache.geronimo.jetty.ApplicationTest Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 8.734 sec [ERROR] TEST org.apache.geronimo.jetty.ApplicationTest FAILED Running org.apache.geronimo.jetty.ContainerTest Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.656 sec Running org.apache.geronimo.jetty.deployment.WebAppDConfigTest Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 4.688 sec [ERROR] TEST org.apache.geronimo.jetty.deployment.WebAppDConfigTest FAILED These errors have happened to me before, so I don't think they are related to the new maven version. Does anyone care? Yes. But from what I remember, these come from restrictions on the firewall on your machine. Given the point of the test is to check that we can connect to the local server over the network suggestions on how to make it work in your environment would be appreciated. If there is more going on here then please post more details (like the text test reports) -- Jeremy
Re: EJB lookup in JNDI?
toby cabot wrote: I guess I should ask first if this functionality (i.e. remote JNDI and EJB calls) is even implemented, maybe I'm trying something that's not built yet. If it's supposed to work I'd welcome any tips people can offer. I don't believe it's there yet. -- Jeremy
RE: Testing Maven 1.0
I'm sorry I don't have any idea about how my company's firewall is set up.
Here are the two test reports for the failed tests.
TEST-org.apache.geronimo.jetty.ApplicationTest.txt
TEST-org.apache.geronimo.jetty.deployment.WebAppDConfigTest.txt
If anyone has suggestions, that would be much appreciated.
Regards,
Peter Lynch
-Original Message-
From: Jeremy Boynes [SMTP:[EMAIL PROTECTED]
Sent: Thursday, July 15, 2004 12:02 PM
To: [EMAIL PROTECTED]
Subject: Re: Testing Maven 1.0
However, I got the following errors:
Running org.apache.geronimo.jetty.ApplicationTest
Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 8.734 sec
[ERROR] TEST org.apache.geronimo.jetty.ApplicationTest FAILED
Running org.apache.geronimo.jetty.ContainerTest
Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.656 sec
Running org.apache.geronimo.jetty.deployment.WebAppDConfigTest
Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 4.688 sec
[ERROR] TEST org.apache.geronimo.jetty.deployment.WebAppDConfigTest
FAILED
These errors have happened to me before, so I don't think they are
related
to the new maven version. Does anyone care?
Yes. But from what I remember, these come from restrictions on the
firewall on your machine. Given the point of the test is to check that
we can connect to the local server over the network suggestions on how
to make it work in your environment would be appreciated.
If there is more going on here then please post more details (like the
text test reports)
--
Jeremy
This communication is confidential and may contain privileged material.
If you are not the intended recipient you must not use, disclose, copy or
retain it.
If you have received it in error please immediately notify me by return email
and delete the emails.
Thank you.
Testsuite: org.apache.geronimo.jetty.ApplicationTest
Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 6.938 sec
- Standard Output ---
Created MBeanServer with ID: 10f11b8:fdc01972b9:-8000:a192419:1
- ---
- Standard Error -
15/07/2004 12:00:18 org.apache.geronimo.kernel.Kernel boot
INFO: Starting boot
15/07/2004 12:00:20 org.apache.geronimo.kernel.Kernel boot
INFO: Booted
15/07/2004 12:00:20 org.mortbay.util.LogSupport clinit
INFO: Log instance is class org.apache.commons.logging.impl.Jdk14Logger
15/07/2004 12:00:20 org.mortbay.http.HttpServer start
INFO: Starting Jetty/5.0.beta0
15/07/2004 12:00:20 org.mortbay.http.HttpServer start
INFO: Started [EMAIL PROTECTED]
15/07/2004 12:00:20 org.mortbay.http.SocketListener start
INFO: Started SocketListener on 0.0.0.0:5678
15/07/2004 12:00:21 org.mortbay.util.FileResource clinit
INFO: Checking Resource aliases
15/07/2004 12:00:23 org.mortbay.xml.XmlParser$Handler error
WARNING: [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee/jsp_2_0.xsd line:140
col:44 : org.xml.sax.SAXParseException: cos-st-restricts.1.1: The type
'jsp-fileType' is atomic, so its {base type definition}, 'j2ee:pathType', must
be an atomic simple type definition or a built-in primitive datatype.
15/07/2004 12:00:24 org.mortbay.jetty.servlet.WebApplicationContext start
WARNING: Configuration error on
file:/D:/incubator-geronimo-1.0-M1/modules/jetty/target/test-classes/deployables/war1
org.xml.sax.SAXParseException: cos-st-restricts.1.1: The type 'jsp-fileType' is
atomic, so its {base type definition}, 'j2ee:pathType', must be an atomic
simple type definition or a built-in primitive datatype.
at
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
Source)
at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at
org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
Source)
at
org.apache.xerces.impl.xs.traversers.XSDAbstractTraverser.reportSchemaError(Unknown
Source)
at
org.apache.xerces.impl.xs.traversers.XSDSimpleTypeTraverser.findDTValidator(Unknown
Source)
at
org.apache.xerces.impl.xs.traversers.XSDSimpleTypeTraverser.traverseSimpleTypeDecl(Unknown
Source)
at
org.apache.xerces.impl.xs.traversers.XSDSimpleTypeTraverser.traverseGlobal(Unknown
Source)
at
org.apache.xerces.impl.xs.traversers.XSDHandler.traverseSchemas(Unknown Source)
at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown
Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.findSchemaGrammar(Unknown Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at
Re: EJB lookup in JNDI?
On Jul 14, 2004, at 5:03 PM, Jeremy Boynes wrote: toby cabot wrote: I guess I should ask first if this functionality (i.e. remote JNDI and EJB calls) is even implemented, maybe I'm trying something that's not built yet. If it's supposed to work I'd welcome any tips people can offer. I don't believe it's there yet. It does, but geronimo and openejb currently have separate jndi providers. If you use these settings instead, it should work: sysproperty key=java.naming.factory.initial value=org.openejb.client.RemoteInitialContextFactory/ sysproperty key=java.naming.provider.url value=25.14.3.92:4201/ -dain
RE: Testing Maven 1.0
Maven 1.0 works using clean and a straight (complete) build on the following: C:\ java -version java version 1.4.2_04 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode) C:\ ver Microsoft Windows 2000 [Version 5.00.2195] maven -clean does: __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0 BUILD SUCCESSFUL Total time: 43 seconds Finished at: Wed Jul 14 13:47:12 CDT 2004 maven (full build) does: | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0 Plugin cache will be regenerated Directory C:\Geronimo\Maven\repository\repository does not exist. Attempting to create. ... BUILD SUCCESSFUL Total time: 26 minutes 21 seconds Finished at: Wed Jul 14 14:15:35 CDT 2004 Thanks David Farb -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 14, 2004 1:33 PM To: [EMAIL PROTECTED] Subject: Testing Maven 1.0 Would appreciate it if people can confirm if geronimo builds on different platforms with the new release of maven 1.0 BUILD SUCCESSFUL on Windows XP Pro SP1 java version 1.4.2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)
Re: problem starting jetty as GBean stanalone
In the future can you start with a fresh email message instead of replying to an existing message on the mailing list. On most email clients if you reply to a message and change the subject it still groups the response with the original thread. BTW this is called thread hijacking. thanks for let me know. will make sure that wan't happen agien :) Anyway, I took a peek at the HTTPConnector code an what you have should work. Can you try hooking up a debugger to see what is in GBeanMBean attributes map? I will try (not still sure how yet , but will find out) any way if there is a bug as I claimed the other peoples build of the maven should failed inside axis module tests. It seems it is not the case. may be I have messs up something, any way plese let me check it, try to debug it and get back to you. Thanks Srinath On Jul 14, 2004, at 1:29 AM, Srinath Perera wrote: The code I was using to start jetty stand alone in AaxisGBean failing. It works just few days ago. in the HTTPConnector GBean the port is defined in the super class sp they are not inherited?? may be this has something to done with this but I am still not sure Then I try code to start the Jetty from ApplicationTest and it also fails saying port is a attribute. If what I saying is true the test should be failing in number of occasions. Thanks Srinath trace = javax.management.AttributeNotFoundException: Unknown attribute port at org.apache.geronimo.gbean.jmx.GBeanMBean.getAttributeByName(GBeanMBean. java:736) at org.apache.geronimo.gbean.jmx.GBeanMBean.setAttribute(GBeanMBean.java: 674) at org.apache.geronimo.axis.AxisGBeanTest.setUp(AxisGBeanTest.java:112) containerName = new ObjectName(geronimo.jetty:role=Container); containerPatterns = Collections.singleton(containerName); connectorName = new ObjectName(geronimo.jetty:role=Connector); appName = new ObjectName(geronimo.jetty:app=test); tmName = new ObjectName(geronimo.test:role=TransactionManager); tcaName = new ObjectName(geronimo.test:role=ConnectionTrackingCoordinator); kernel = new Kernel(test.kernel, test); kernel.boot(); mbServer = kernel.getMBeanServer(); container = new GBeanMBean(JettyContainerImpl.GBEAN_INFO); connector = new GBeanMBean(HTTPConnector.GBEAN_INFO); connector.setAttribute(port, new Integer(5678)); connector.setReferencePatterns(JettyContainer, containerPatterns); start(containerName, container); start(connectorName, connector); tm = new GBeanMBean(GeronimoTransactionManager.GBEAN_INFO); Set patterns = new HashSet(); patterns.add(ObjectName.getInstance(geronimo.server: j2eeType=JCAManagedConnectionFactory,*)); tm.setReferencePatterns(resourceManagers, patterns); start(tmName, tm); ctc = new GBeanMBean(ConnectionTrackingCoordinator.GBEAN_INFO); start(tcaName, ctc); Lanka Sofware Foundation
Re: problem starting jetty as GBean stanalone
Anyway, I took a peek at the HTTPConnector code an what you have should work. Can you try hooking up a debugger to see what is in GBeanMBean attributes map? I will try (not still sure how yet , but will find out) any way if there is a bug as I claimed the other peoples build of the maven should failed inside axis module tests. It seems it is not the case. may be I have messs up something, any way plese let me check it, try to debug it and get back to you. Thanks Srinath yes when I build all geronimo with tests off and then build the axis module back and in that case it works ok. Srinath On Jul 14, 2004, at 1:29 AM, Srinath Perera wrote: The code I was using to start jetty stand alone in AaxisGBean failing. It works just few days ago. in the HTTPConnector GBean the port is defined in the super class sp they are not inherited?? may be this has something to done with this but I am still not sure Then I try code to start the Jetty from ApplicationTest and it also fails saying port is a attribute. If what I saying is true the test should be failing in number of occasions. Thanks Srinath trace = javax.management.AttributeNotFoundException: Unknown attribute port at org.apache.geronimo.gbean.jmx.GBeanMBean.getAttributeByName(GBeanMBean. java:736) at org.apache.geronimo.gbean.jmx.GBeanMBean.setAttribute(GBeanMBean.java: 674) at org.apache.geronimo.axis.AxisGBeanTest.setUp(AxisGBeanTest.java:112) containerName = new ObjectName(geronimo.jetty:role=Container); containerPatterns = Collections.singleton(containerName); connectorName = new ObjectName(geronimo.jetty:role=Connector); appName = new ObjectName(geronimo.jetty:app=test); tmName = new ObjectName(geronimo.test:role=TransactionManager); tcaName = new ObjectName(geronimo.test:role=ConnectionTrackingCoordinator); kernel = new Kernel(test.kernel, test); kernel.boot(); mbServer = kernel.getMBeanServer(); container = new GBeanMBean(JettyContainerImpl.GBEAN_INFO); connector = new GBeanMBean(HTTPConnector.GBEAN_INFO); connector.setAttribute(port, new Integer(5678)); connector.setReferencePatterns(JettyContainer, containerPatterns); start(containerName, container); start(connectorName, connector); tm = new GBeanMBean(GeronimoTransactionManager.GBEAN_INFO); Set patterns = new HashSet(); patterns.add(ObjectName.getInstance(geronimo.server: j2eeType=JCAManagedConnectionFactory,*)); tm.setReferencePatterns(resourceManagers, patterns); start(tmName, tm); ctc = new GBeanMBean(ConnectionTrackingCoordinator.GBEAN_INFO); start(tcaName, ctc); Lanka Sofware Foundation Lanka Sofware Foundation
Re: Testing Maven 1.0
Build Successful with maven 1.0 Windows 2000 5.00.2195 SP 3 java version 1.4.1_02 Java(TM) 2 Runtime Environment, Standard Edition(build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) Thanks, Dev At 11:32 AM 7/14/2004, Jeremy Boynes wrote: Would appreciate it if people can confirm if geronimo builds on different platforms with the new release of maven 1.0 BUILD SUCCESSFUL on Windows XP Pro SP1 java version 1.4.2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)
Re: Javamail license
--- Dain Sundstrom [EMAIL PROTECTED] wrote: snipped Does the ASF allow us to ship software from ASF servers that contain dependencies that have this kind of language? Jakarta Tomcat still ships the javamail jar. -dain -- Sriram __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail
Re: Testing Maven 1.0
Hi Jeremy Boynes wrote: Yes. But from what I remember, these come from restrictions on the firewall on your machine. Given the point of the test is to check that we can connect to the local server over the network suggestions on how to make it work in your environment would be appreciated. The old problem. Geronimo doesn't build offline. ApplicationTest and WebAppDConfigTest parses a web.xml file and the parser tries to resolve the DTD. There is no entityresolver configured at that moment. That's what I've done to make it work behind the firewall: I modified my etc.host file (for windows: C:\WINNT\system32\drivers\etc\hosts ) to resolve the java.sun.com locally. --- 8 --- ... 127.0.0.1 java.sun.com ... --- 8 --- I configured putty to tunnel local port 80 to java.sun.com:80 Kristian
Re: [jira] Created: (GERONIMO-267) NoSuchOperationError on deployment of SSB
On 15/07/2004 3:10 AM, Dain Sundstrom wrote: On Jul 14, 2004, at 4:47 AM, Gianny Damour wrote: Sorry; indeed, this is perhaps not the right approach. However, I was pretty confident that this new behavior was more correct: As far as I understand, the JMX GBeanInvokers are used only when the framework mounts a reference, which does not have an attribute named GBeanMBean.RAW_INVOKER. Most of the time, this means that the reference is an home-made MBean (an MBean, which is not a GBeanMBean). So, I thought that we could safely say that programmers have applied the JMX standards. In other words, if the attribute is named serverVersion, then the getter must be getserverVersion. When you want to interact with a GBean over a remote MBean server (JSR 160), you will use the JMXGBeanInvokers. Also, this is an attempt to make our interactions through JMX easier. Thanks for that; it was a missing block in my reasoning. I definitely think the two should work exactly the same and the programmer should not know which one is being used (other then the JMX one is way slower). My biggest reason to have these work the same is the person using the GBeanInvoker is caller, and the caller would have to know how the target GBean was implemented in order to get the calling code correct. You are right. So, to sum it up, in a first pass one applies the JMX standards; and in case of failure, a case insensitive match of method and attribute names is performed. Thanks, Gianny
Anyone working on EJB 2.1 Timer support
Is anyone working on EJB 2.1 Timer support? Would it be ok to develop this feature for Geronimo? Thanks, Dev
Re: EJB lookup in JNDI? (that works)
On Thu, Jul 15, 2004 at 11:47:58AM -0500, David Blevins wrote: Is it complaining when they are not there or just when they are specified in the system properties? It complains if they're not there; and if they're set in system properties it doesn't see them (and complains). It works if they're set in a Properties that's passed to the InitialContext constructor. Thanks, Toby
Re: Anyone working on EJB 2.1 Timer support
I've been working on 2.1 timer support at the OpenEJB level [since the EJB stuff is all at that level] on and off over the last ~3 months. I've unfortunately been in and out of the hospital over the last 2 months so my work hasn't progressed as I'd like it to. If you're interested, we could certainly put our heads together and I can give you my notes, etc. and we can see if two heads maybe aren't better than one. Due to various complications, etc. alot of my stuff is written ideas/notes/sketches of interfaces right now which need to be fleshed out. -Brendan On Jul 15, 2004, at 13:58, Dev wrote: Is anyone working on EJB 2.1 Timer support? Would it be ok to develop this feature for Geronimo? Thanks, Dev
Re: build broken (assembly module)?
Can you check that your openejb copy is up to date? I've been trying to fix these case problems in both projects while doing actual development work and I think but am not entirely sure that at least this problem is fixed. These attribute names should start with lower case as in cvs. thanks david jencks On Thursday, July 15, 2004, at 02:28 PM, toby cabot wrote: Are other people seeing build breakage in the assembly module? Something about attribute names not found. This patch seems to work (changing a couple of attribute names from lower case to upper case): diff -u -r1.37 j2ee-server-plan.xml --- modules/assembly/src/plan/j2ee-server-plan.xml 15 Jul 2004 20:38:21 - 1.37 +++ modules/assembly/src/plan/j2ee-server-plan.xml 15 Jul 2004 21:25:43 - @@ -188,13 +188,13 @@ !-- EJB Protocol -- gbean name=openejb:type=SocketService,name=EJB class=org.openejb.server.SimpleSocketService -attribute name=serviceClassName type=java.lang.Stringorg.openejb.server.ejbd.EjbServer/attribute -attribute name=onlyFrom type=java.net.InetAddress[]127.0.0.1/attribute +attribute name=ServiceClassName type=java.lang.Stringorg.openejb.server.ejbd.EjbServer/attribute +attribute name=OnlyFrom type=java.net.InetAddress[]127.0.0.1/attribute reference name=ContainerIndexopenejb:type=ContainerIndex/reference /gbean gbean name=openejb:type=ServiceDaemon,name=EJB class=org.openejb.server.ServiceDaemon -attribute name=port type=int4201/attribute -attribute name=inetAddress type=java.net.InetAddress127.0.0.1/attribute +attribute name=Port type=int4201/attribute +attribute name=InetAddress type=java.net.InetAddress127.0.0.1/attribute reference name=SocketServiceopenejb:type=SocketService,name=EJB/reference /gbean
Re: Thread pool strategy
On Jul 13, 2004, at 5:39 PM, toby cabot wrote: On Tue, Jul 13, 2004 at 03:33:35PM -0400, Geir Magnusson Jr wrote: Is it really now as in if you don't have to wait for a thread, do it - otherwise return w/ a status indicating now wasn't possible or now as in wait until there's a thread, do it, and then return to me? three choices: doWork() - block until it's done startWork() - block until it starts and then return scheduleWork() - return now and do the work whenever. http://java.sun.com/j2ee/1.4/docs/api/javax/resource/spi/work/ WorkManager.html Reading the javadoc, all three have a param which lets me specify that the work must start immediately or be rejected. Perfect :) geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED]
[jira] Closed: (GERONIMO-267) NoSuchOperationError on deployment of SSB
Message: The following issue has been closed. Resolver: Gianny DAMOUR Date: Thu, 15 Jul 2004 3:58 PM A temporary fix has been applied in order to be backward compatible with the previous attribute name conventions. - View the issue: http://issues.apache.org/jira/browse/GERONIMO-267 Here is an overview of the issue: - Key: GERONIMO-267 Summary: NoSuchOperationError on deployment of SSB Type: Bug Status: Closed Priority: Major Resolution: FIXED Project: Apache Geronimo Components: deployment Fix Fors: 1.0-M2 Versions: 1.0-M2 Assignee: Gianny DAMOUR Reporter: toby cabot Created: Tue, 13 Jul 2004 1:44 PM Updated: Thu, 15 Jul 2004 3:58 PM Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) Description: i'm trying to deploy and run the test ejb in ./modules/j2ee/target/test-ejb.jar. after fixing the ejb-jar.xml (see bug 266) it deploys cleanly but when I bring the server up I get a org.apache.geronimo.gbean.jmx.NoSuchOperationError: 10:24:17,874 DEBUG [GBeanMBean] geronimo.server:J2EEApplication=skeleton/app,J2EEServer=geronimo,j2eeType=WebModule,name=skeleton-web.war State changed from starting to running 10:24:17,920 DEBUG [GBeanMBean] geronimo.server:J2EEApplication=skeleton/app,J2EEModule=skeleton-ejb.jar,J2EEServer=geronimo,j2eeType=StatelessSessionBean,name=StatelessSession State changed from starting to running 10:24:17,987 ERROR [CollectionProxy] Listener threw exception org.apache.geronimo.gbean.jmx.NoSuchOperationError: No implementation method: objectName=geronimo.server:J2EEApplication=skeleton/app,J2EEModule=skeleton-ejb.jar,J2EEServer=geronimo,j2eeType=StatelessSessionBean,name=StatelessSession, method=public abstract org.openejb.EJBContainer org.openejb.EJBContainer.getUnmanagedReference() at org.apache.geronimo.gbean.jmx.CGLibMethodInterceptor.intercept(CGLibMethodInterceptor.java:108) at org.openejb.EJBContainer$$EnhancerByCGLIB$$9c51bc0b.getUnmanagedReference(generated) at org.openejb.ContainerIndex.addContainer(ContainerIndex.java:137) at org.openejb.ContainerIndex.memberAdded(ContainerIndex.java:168) at org.apache.geronimo.gbean.jmx.CollectionProxy$ClientCollection.fireMemberAdddedEvent(CollectionProxy.java:180) at org.apache.geronimo.gbean.jmx.CollectionProxy$ClientCollection.access$200(CollectionProxy.java:151) at org.apache.geronimo.gbean.jmx.CollectionProxy.addTarget(CollectionProxy.java:117) at org.apache.geronimo.gbean.jmx.GBeanMBeanReference.handleNotification(GBeanMBeanReference.java:298) at mx4j.server.interceptor.NotificationListenerMBeanServerInterceptor$ListenerWrapper.handleNotification(NotificationListenerMBeanServerInterceptor.java:57) at javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:346) at javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:320) at org.apache.geronimo.gbean.jmx.AbstractManagedObject.sendNotification(AbstractManagedObject.java:244) at org.apache.geronimo.gbean.jmx.AbstractManagedObject.attemptFullStart(AbstractManagedObject.java:500) at org.apache.geronimo.gbean.jmx.SingleProxy.attemptFullStart(SingleProxy.java:154) at org.apache.geronimo.gbean.jmx.SingleProxy.addTarget(SingleProxy.java:119) at org.apache.geronimo.gbean.jmx.GBeanMBeanReference.handleNotification(GBeanMBeanReference.java:298) at mx4j.server.interceptor.NotificationListenerMBeanServerInterceptor$ListenerWrapper.handleNotification(NotificationListenerMBeanServerInterceptor.java:57) at javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:346) at javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:320) at org.apache.geronimo.gbean.jmx.AbstractManagedObject.sendNotification(AbstractManagedObject.java:244) at org.apache.geronimo.gbean.jmx.AbstractManagedObject.attemptFullStart(AbstractManagedObject.java:500) at org.apache.geronimo.gbean.jmx.AbstractManagedObject.start(AbstractManagedObject.java:279) at org.apache.geronimo.gbean.jmx.AbstractManagedObject.startRecursive(AbstractManagedObject.java:303) at org.apache.geronimo.gbean.jmx.GBeanMBean$9.invoke(GBeanMBean.java:940) at org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142) at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:767) at mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerMBeanServerInterceptor.java:218) at
