Re: build broken (assembly module)?
On 16/07/2004 7:54 AM, David Jencks wrote: 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. This is weird. The http://dist.codehaus.org maven repository does not seem to be up-to-date: the itests and jca archives have been updated on 15-Jul-2004 and the last update of core was on 12-Jul-2004. In other words, assembly still fail. Thanks, Gianny
Re: build broken (assembly module)?
On Thursday, July 15, 2004, at 04:50 PM, Gianny Damour wrote: On 16/07/2004 7:54 AM, David Jencks wrote: 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. This is weird. The http://dist.codehaus.org maven repository does not seem to be up-to-date: the itests and jca archives have been updated on 15-Jul-2004 and the last update of core was on 12-Jul-2004. In other words, assembly still fail. I meant up to date with cvs. If someone is making related changes on both projects, trying to use a snapshot of one isn't going to work. thanks david jencks Thanks, Gianny
Re: build broken (assembly module)?
On Thu, Jul 15, 2004 at 02:54:27PM -0700, David Jencks wrote: Can you check that your openejb copy is up to date? I did a CVS pull and a maven clean maven, is there anything more I need to do? 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. OK, here's more data. I have a resource adapter with a config-property called group (or maybe Group). Anyway, the bean setter is setGroup(String group). If I put config-property-namegroup/config-property-name in geronimo-ra.xml I get (at startup): 08:45:36,921 DEBUG [GBeanMBean] geronimo.config:name=reva/spreadRA State changed from stopped to starting 08:45:36,966 DEBUG [Configuration] ClassPath for reva/spreadRA resolved to [file:/home/tcabot/try/incubator-geronimo/target/config-store/13/connector/spread-3.17.0.jar, file:/home/tcabot/try/incubator-geronimo/target/config-store/13/connector/x-spread.jar] 08:45:37,127 ERROR [Configuration] caught in doStart(): java.lang.IllegalArgumentException: reva.x.ra.spread.AdapterImpl: unknown attribute group at org.apache.geronimo.gbean.DynamicGBeanDelegate.setAttribute(DynamicGBeanDelegate.java:119) at org.apache.geronimo.connector.ResourceAdapterWrapper.setAttribute(ResourceAdapterWrapper.java:131) at org.apache.geronimo.gbean.jmx.GBeanMBeanAttribute$DynamicSetterMethodInvoker.invoke(GBeanMBeanAttribute.java:473) at org.apache.geronimo.gbean.jmx.GBeanMBeanAttribute.online(GBeanMBeanAttribute.java:273) at org.apache.geronimo.gbean.jmx.GBeanMBean.preRegister(GBeanMBean.java:537) at mx4j.server.interceptor.InvokerMBeanServerInterceptor.registration(InvokerMBeanServerInterceptor.java:158) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.registration(DefaultMBeanServerInterceptor.java:111) at mx4j.server.interceptor.SecurityMBeanServerInterceptor.registration(SecurityMBeanServerInterceptor.java:135) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.registration(DefaultMBeanServerInterceptor.java:111) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.registration(DefaultMBeanServerInterceptor.java:111) at mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.registration(ContextClassLoaderMBeanServerInterceptor.java:161) at mx4j.server.MX4JMBeanServer.registerImpl(MX4JMBeanServer.java:801) at mx4j.server.MX4JMBeanServer.registerMBeanImpl(MX4JMBeanServer.java:745) at mx4j.server.MX4JMBeanServer.registerMBean(MX4JMBeanServer.java:729) at org.apache.geronimo.kernel.Kernel.loadGBean(Kernel.java:254) If I change it to config-property-namegroup/config-property-name I get (at shutdown): 17:59:22,292 DEBUG [GBeanMBean] geronimo.config:name=reva/spreadRA State changed from running to stopping 17:59:22,292 INFO [Configuration] Stopping configuration reva/spreadRA 17:59:22,332 ERROR [GBeanMBeanAttribute] Could not get the current value of persistent attribute while going offline. The persistent attribute will not reflect the current state attribute. Attribute Name: Group, Type: class java.lang.Object, GBean: org.apache.geronimo.connector.ResourceAdapterWrapper java.lang.IllegalArgumentException: reva.x.ra.spread.AdapterImpl: unknown attribute Group at org.apache.geronimo.gbean.DynamicGBeanDelegate.getAttribute(DynamicGBeanDelegate.java:111) at org.apache.geronimo.connector.ResourceAdapterWrapper.getAttribute(ResourceAdapterWrapper.java:127) at org.apache.geronimo.gbean.jmx.GBeanMBeanAttribute$DynamicGetterMethodInvoker.invoke(GBeanMBeanAttribute.java:461) at org.apache.geronimo.gbean.jmx.GBeanMBeanAttribute.offline(GBeanMBeanAttribute.java:289) at org.apache.geronimo.gbean.jmx.GBeanMBean.postDeregister(GBeanMBean.java:572) at mx4j.server.interceptor.InvokerMBeanServerInterceptor.registration(InvokerMBeanServerInterceptor.java:171) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.registration(DefaultMBeanServerInterceptor.java:111) at mx4j.server.interceptor.SecurityMBeanServerInterceptor.registration(SecurityMBeanServerInterceptor.java:135) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.registration(DefaultMBeanServerInterceptor.java:111) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.registration(DefaultMBeanServerInterceptor.java:111) at mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.registration(ContextClassLoaderMBeanServerInterceptor.java:161) at mx4j.server.MX4JMBeanServer.unregisterMBean(MX4JMBeanServer.java:949) So it looks like we're internally inconsistent. Based on what you said it looks as if the right value is group so the bug is in the startup code. Might be the same bug I noted in the
[jira] Updated: (GERONIMO-264) exceptions being swallowed at startup
The following issue has been updated: Updater: toby cabot (mailto:[EMAIL PROTECTED]) Date: Fri, 16 Jul 2004 6:40 AM Changes: Attachment changed to daemon-log.diff - For a full history of the issue, see: http://issues.apache.org/jira/browse/GERONIMO-264?page=history - View the issue: http://issues.apache.org/jira/browse/GERONIMO-264 Here is an overview of the issue: - Key: GERONIMO-264 Summary: exceptions being swallowed at startup Type: Improvement Status: Unassigned Priority: Minor Project: Apache Geronimo Components: deployment Versions: 1.0-M2 Assignee: Reporter: toby cabot Created: Mon, 12 Jul 2004 1:06 PM Updated: Fri, 16 Jul 2004 6:40 AM Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) Description: some exceptions that are thrown during startup are swallowed and don't show up in the logs. i'm at the 'monkey and typewriter' stage of the geronimo learning curve so i'm a good randomness injector. i had a problem where geronimo would try to start up and then go directly to shutdown for no apparent reason. actually, i think i've had a few: 15:50:17,290 DEBUG [GBeanMBean] geronimo.config:name=skeleton/RA State changed from stopped to starting 15:50:17,292 DEBUG [Configuration] ClassPath for skeleton/RA resolved to [file:/home/tcabot/try/incubator-geronimo/target/config-store/8/connector/skeleton-ra.jar] ra test setting configParameter to NewStringValue 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] BaseManagedConnectionFactory() 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] SpreadManagedConnectionFactory() 15:50:18,425 DEBUG [GBeanMBean] geronimo.config:name=skeleton/RA State changed from starting to failed 15:50:18,426 INFO [Kernel] Starting kernel shutdown i'll include a patch that logs the problem in the catch clause in Configuration.doStart(). There might be better places to do this, but as long as it gets done *somewhere* i'm happy. regards, toby - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-264) exceptions being swallowed at startup
The following comment has been added to this issue: Author: toby cabot Created: Fri, 16 Jul 2004 6:44 AM Body: just noticed that my patch has a typo in one of the log messages: staring kernel shutdown should be starting kernel shutdown. if only log4j had a grammar checker... - View this comment: http://issues.apache.org/jira/browse/GERONIMO-264?page=comments#action_36714 - View the issue: http://issues.apache.org/jira/browse/GERONIMO-264 Here is an overview of the issue: - Key: GERONIMO-264 Summary: exceptions being swallowed at startup Type: Improvement Status: Unassigned Priority: Minor Project: Apache Geronimo Components: deployment Versions: 1.0-M2 Assignee: Reporter: toby cabot Created: Mon, 12 Jul 2004 1:06 PM Updated: Fri, 16 Jul 2004 6:44 AM Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) Description: some exceptions that are thrown during startup are swallowed and don't show up in the logs. i'm at the 'monkey and typewriter' stage of the geronimo learning curve so i'm a good randomness injector. i had a problem where geronimo would try to start up and then go directly to shutdown for no apparent reason. actually, i think i've had a few: 15:50:17,290 DEBUG [GBeanMBean] geronimo.config:name=skeleton/RA State changed from stopped to starting 15:50:17,292 DEBUG [Configuration] ClassPath for skeleton/RA resolved to [file:/home/tcabot/try/incubator-geronimo/target/config-store/8/connector/skeleton-ra.jar] ra test setting configParameter to NewStringValue 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] BaseManagedConnectionFactory() 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] SpreadManagedConnectionFactory() 15:50:18,425 DEBUG [GBeanMBean] geronimo.config:name=skeleton/RA State changed from starting to failed 15:50:18,426 INFO [Kernel] Starting kernel shutdown i'll include a patch that logs the problem in the catch clause in Configuration.doStart(). There might be better places to do this, but as long as it gets done *somewhere* i'm happy. regards, toby - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-264) exceptions being swallowed at startup
Message: The following issue has been re-assigned. Assignee: Dain Sundstrom (mailto:[EMAIL PROTECTED]) Assigner: Jeremy Boynes (mailto:[EMAIL PROTECTED]) Date: Fri, 16 Jul 2004 10:39 AM Comment: Toby, thanks The reason this class was using System.err was because it was running before the logging subsystem had chance to start. I'm going to assign this to Dain as he is more familiar with logging and would know if this is a valid thing to do. - View the issue: http://issues.apache.org/jira/browse/GERONIMO-264 Here is an overview of the issue: - Key: GERONIMO-264 Summary: exceptions being swallowed at startup Type: Improvement Status: Open Priority: Minor Project: Apache Geronimo Components: deployment Versions: 1.0-M2 Assignee: Dain Sundstrom Reporter: toby cabot Created: Mon, 12 Jul 2004 1:06 PM Updated: Fri, 16 Jul 2004 10:39 AM Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) Description: some exceptions that are thrown during startup are swallowed and don't show up in the logs. i'm at the 'monkey and typewriter' stage of the geronimo learning curve so i'm a good randomness injector. i had a problem where geronimo would try to start up and then go directly to shutdown for no apparent reason. actually, i think i've had a few: 15:50:17,290 DEBUG [GBeanMBean] geronimo.config:name=skeleton/RA State changed from stopped to starting 15:50:17,292 DEBUG [Configuration] ClassPath for skeleton/RA resolved to [file:/home/tcabot/try/incubator-geronimo/target/config-store/8/connector/skeleton-ra.jar] ra test setting configParameter to NewStringValue 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] BaseManagedConnectionFactory() 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] SpreadManagedConnectionFactory() 15:50:18,425 DEBUG [GBeanMBean] geronimo.config:name=skeleton/RA State changed from starting to failed 15:50:18,426 INFO [Kernel] Starting kernel shutdown i'll include a patch that logs the problem in the catch clause in Configuration.doStart(). There might be better places to do this, but as long as it gets done *somewhere* i'm happy. regards, toby - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: Thread pool strategy
On Wed, 14 Jul 2004, Geir Magnusson Jr wrote: | | 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 | | Thx. needs one more : | | doWorkNow() startHardWork() doWorkSmarter() doSmartWork() scheduleWorkLater() weekendNow() Endre.sleep()
[jira] Commented: (GERONIMO-264) exceptions being swallowed at startup
The following comment has been added to this issue: Author: toby cabot Created: Fri, 16 Jul 2004 11:16 AM Body: Thanks Jeremy, I think that using the logger in this class should be OK since this class initializes it in a static block. - View this comment: http://issues.apache.org/jira/browse/GERONIMO-264?page=comments#action_36718 - View the issue: http://issues.apache.org/jira/browse/GERONIMO-264 Here is an overview of the issue: - Key: GERONIMO-264 Summary: exceptions being swallowed at startup Type: Improvement Status: Open Priority: Minor Project: Apache Geronimo Components: deployment Versions: 1.0-M2 Assignee: Dain Sundstrom Reporter: toby cabot Created: Mon, 12 Jul 2004 1:06 PM Updated: Fri, 16 Jul 2004 11:16 AM Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) Description: some exceptions that are thrown during startup are swallowed and don't show up in the logs. i'm at the 'monkey and typewriter' stage of the geronimo learning curve so i'm a good randomness injector. i had a problem where geronimo would try to start up and then go directly to shutdown for no apparent reason. actually, i think i've had a few: 15:50:17,290 DEBUG [GBeanMBean] geronimo.config:name=skeleton/RA State changed from stopped to starting 15:50:17,292 DEBUG [Configuration] ClassPath for skeleton/RA resolved to [file:/home/tcabot/try/incubator-geronimo/target/config-store/8/connector/skeleton-ra.jar] ra test setting configParameter to NewStringValue 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] BaseManagedConnectionFactory() 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] SpreadManagedConnectionFactory() 15:50:18,425 DEBUG [GBeanMBean] geronimo.config:name=skeleton/RA State changed from starting to failed 15:50:18,426 INFO [Kernel] Starting kernel shutdown i'll include a patch that logs the problem in the catch clause in Configuration.doStart(). There might be better places to do this, but as long as it gets done *somewhere* i'm happy. regards, toby - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
