geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nina Rinskaya (JIRA)" <j...@apache.org>
Subject [jira] Created: (GERONIMO-3323) [testing] org.apache.geronimo.gjndi.binding.GBeanBindingTest fails on Apache Harmony because it relies on GBeans startup order which is not guaranteed
Date Sun, 15 Jul 2007 09:37:04 GMT
[testing] org.apache.geronimo.gjndi.binding.GBeanBindingTest fails on Apache Harmony because
it relies on GBeans startup order which is not guaranteed
------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: GERONIMO-3323
                 URL: https://issues.apache.org/jira/browse/GERONIMO-3323
             Project: Geronimo
          Issue Type: Bug
      Security Level: public (Regular issues)
          Components: naming
    Affects Versions: 1.2
            Reporter: Nina Rinskaya
            Priority: Minor


It looks that org.apache.geronimo.gjndi.binding.GBeanBindingTest fails on Apache Harmony because
it relies on GBeans startup order which is not guaranteed as far as I understand.

it supposes that GBeanData that has an empty AbstractNameQuery.name will be bound to a specific
GBean:
org.apache.geronimo.gjndi.binding.GBeanBindingTest.java:
...
        GBeanData dsBinding = configurationData.addGBean("dsBinding", GBeanBinding.GBEAN_INFO);
        dsBinding.setReferencePattern("Context", writableName);
        dsBinding.setAttribute("name", "ds");
	AbstractNameQuery abstractNameQuery = new AbstractNameQuery(null, Collections.EMPTY_MAP,
DataSource.class.getName());
        dsBinding.setAttribute("abstractNameQuery", abstractNameQuery);
...
        globalBindings.put("writable/ds", ds1);
...

But org.apache.geronimo.gjndi.binding.GBeanBinding.doStart() says:
...
        Set set = kernel.listGBeans(abstractNameQuery);
        for (Iterator iterator = set.iterator(); iterator.hasNext();) {
            AbstractName abstractName = (AbstractName) iterator.next();
            try {
                if (kernel.isRunning(abstractName)) {
                    addBinding(abstractName);
                }
            } catch (NamingException e) {
                log.error("Error adding binding for " + abstractName, e);
            }
        }
...
For an abstractNameQuery with an empty map as a name (that corresponds to dsBinding) it will
iterate through both ds1 and ds2, checking that the kernel is running thie gbean and trying
to bind. For Sun VM ds1 is started by the moment of binding and ds2 isn't, then dsBinding
is bound to ds1. When running on Harmony, both ds1 and ds2 are running by the moment of binding
and it first checks ds2 and then ds1 (the order is not guaranteed as far as I understand),
and then dsBinding is bound to ds2 and assertion fails.

Note, that if we replace substring ds1 with ds2 in the test, then the test will fail on Sun
VM (because then ds1 still will be run first, but ds will be expected to be bound to ds2)
and pass on Harmony VM.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message