Yes, sure. I had to replace the keystore, patch the geronimo-security sources and make other adjustments. See [1] for the details.
And anyway Geronimo doesn't work very good for now, still many problems are visible (e .g., the console almost doesn't work) and need to be investigated and fixed. Vasily [1] http://cwiki.apache.org/confluence/display/GMOxDOC20/Apache+Harmony -----Original Message----- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, January 17, 2008 11:24 AM To: dev@geronimo.apache.org Subject: Re: MailGBean/JNDI problem on Harmony Nice. But it starts with patched key store as far as I understand... right? SY, Alexey https://issues.apache.org/jira/browse/GERONIMO-2015 2008/1/16, Zakharov, Vasily M <[EMAIL PROTECTED]>: > > Sorry for disturbing, I've just found out the cause for this issue - I > had one extra property in config.xml. If namingFactoryInitial > specification is removed, and namingFactoryUrlPkgs specification is > retained, the problem is resolved, and Geronimo starts fine on Harmony. > > Vasily > > > -----Original Message----- > From: Zakharov, Vasily M [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 16, 2008 8:53 PM > To: dev@geronimo.apache.org > Subject: MailGBean/JNDI problem on Harmony > > Hi, all, > > I'm found a problem with MailGBean on Harmony due to of JNDI > configuration, and I'm asking for help to understand how to deal with > that problem. The problem would occur on any JDK lacking Sun > implementation of JNDI RMI Registry provider > (com.sun.jndi.rmi.registry.RegistryContext). The problem occurs at > startup and looks as follows: > > java.lang.IllegalArgumentException: Cannot bind to RMI Registry object > that is neither Remote nor Reference nor Referenceable > at > org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.getStateTo > Bind(RegistryContext.java:618) > at > org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.bind(Regis > tryContext.java:266) > at > org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.bind(Regis > tryContext.java:280) > at javax.naming.InitialContext.bind(InitialContext.java:411) > at > org.apache.geronimo.mail.MailGBean.doStart(MailGBean.java:385) > > The investigation shows the following difference of MailGBean code > operation on Sun and Harmony: > > On Sun, the InitialContext.getEnvironment() is empty, and > InitialContext.lookup("") returns > org.apache.geronimo.gjndi.GlobalContextGBean, and > InitialContext.getNameParser("") returns > org.apache.xbean.naming.context.ContextUtil$SimpleNameParser. > > On Harmony, this works much differently - > InitialContext.getEnvironment() contains the JNDI properties specified > in config.xml, and InitialContext.lookup("") returns > org.apache.harmony.jndi.provider.rmi.registry.RegistryContext, and > InitialContext.getNameParser("") returns > org.apache.harmony.jndi.provider.rmi.registry.AtomicNameParser. > This causes the error above. > > I had to specify the respective JNDI properties in config.xml for > JMXConnector to start normally, as follows: > > <module name="org.apache.geronimo.configs/rmi-naming/2.0.2/car"> > <gbean name="NamingProperties"> > <attribute > name="namingFactoryInitial">org.apache.harmony.jndi.provider.rmi.registr > y.RegistryContextFactory</attribute> > <attribute > name="namingFactoryUrlPkgs">org.apache.harmony.jndi.provider</attribute> > <attribute name="namingProviderUrl">rmi://${ServerHostname}:${NamingPort > + PortOffset}</attribute> > </gbean> > > Probably this is wrong to configure JNDI this way, as it overrides > Geronimo internal naming mechanisms? > > Maybe org.apache.geronimo.gjndi.GlobalContextGBean needs to be tweaked > to find the proper JNDI RMI Registry provider by other means than > standard JNDI properties? > > I'd be happy to hear any ideas, considerations or suggestions on this > issue. > > Thank you very much! > > Vasily Zakharov > Intel ESSD > > > > --- > >
