Reference com.day.commons.simplejndi.impl.ContextService in component | Community
Skip to main content
Level 2
February 27, 2019
Solved

Reference com.day.commons.simplejndi.impl.ContextService in component

  • February 27, 2019
  • 2 replies
  • 1418 views

Hi,

I am implementing a component which can validate email address.

For using MX record to validate email, I need to use jndi as below:

  1. int doLookup( String hostName ) throws NamingException { 
  2.     Hashtable env = new Hashtable(); 
  3.     env.put("java.naming.factory.initial"
  4.             "com.sun.jndi.dns.DnsContextFactory"); 
  5.     DirContext ictx = new InitialDirContext( env ); 
  6.     Attributes attrs =  
  7.        ictx.getAttributes( hostName, new String[] { "MX" }); 
  8.     Attribute attr = attrs.get( "MX" ); 
  9.     if( attr == null ) return( 0 ); 
  10.     return( attr.size() ); 
  11.   } 

In osgi container, usage of standard JNDI APIs could break modularity in OSGI applications. As expected, directly using javax.naming.directory.InitialDirContext gives javax.naming.NotContextException: Not an instance of DirContext.

Then tried to use com.day.commons.simplejndi.impl.ContextService and the component was in satisfied state.

Below is the error log:

27.02.2019 14:24:46.351 *ERROR* [CM Event Dispatcher (Fire ConfigurationEvent: pid=com.telstra.media.puck.services.impl.EmailServiceImpl)] org.apache.felix.configadmin Service [org.apache.felix.cm.ConfigurationAdmin,21, [org.osgi.service.cm.ConfigurationAdmin]] Unexpected problem delivering configuration event to [org.osgi.service.cm.ConfigurationListener, id=40, bundle=27/launchpad:resources/install/4/org.apache.felix.scr-2.0.2.jar] (java.lang.NoClassDefFoundError: com/day/commons/simplejndi/impl/ContextService)

java.lang.NoClassDefFoundError: com/day/commons/simplejndi/impl/ContextService

        at java.lang.Class.getDeclaredMethods0(Native Method) ~[na:1.8.0_91]

        at java.lang.Class.privateGetDeclaredMethods(Class.java:2701) ~[na:1.8.0_91]

        at java.lang.Class.getDeclaredMethods(Class.java:1975) ~[na:1.8.0_91]

        at org.apache.felix.scr.impl.helper.BindMethod.getServiceObjectAssignableMethod(BindMethod.java:454) ~[na:na]

        at org.apache.felix.scr.impl.helper.BindMethod.doFindMethod(BindMethod.java:186) ~[na:na]

        at org.apache.felix.scr.impl.helper.BaseMethod.findMethod(BaseMethod.java:171) ~[na:na]

        at org.apache.felix.scr.impl.helper.BaseMethod.access$400(BaseMethod.java:37) ~[na:na]

        at org.apache.felix.scr.impl.helper.BaseMethod$NotResolved.resolve(BaseMethod.java:558) ~[na:na]

        at org.apache.felix.scr.impl.helper.BaseMethod$NotResolved.methodExists(BaseMethod.java:580) ~[na:na]

        at org.apache.felix.scr.impl.helper.BaseMethod.methodExists(BaseMethod.java:513) ~[na:na]

        at org.apache.felix.scr.impl.helper.BindMethod.getServiceObject(BindMethod.java:643) ~[na:na]

        at org.apache.felix.scr.impl.manager.DependencyManager.getServiceObject(DependencyManager.java:2137) ~[na:na]

        at org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.prebind(DependencyManager.java:1048) ~[na:na]

        at org.apache.felix.scr.impl.manager.DependencyManager.prebind(DependencyManager.java:1457) ~[na:na]

        at org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:983) ~[na:na]

        at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:812) ~[na:na]

        at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:724) ~[na:na]

        at org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:627) ~[na:na]

        at org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:566) ~[na:na]

        at org.apache.felix.scr.impl.config.ConfigurableComponentHolder.configurationUpdated(ConfigurableComponentHolder.java:419) ~[na:na]

        at org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:315) ~[na:na]

        at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2046) [!/:na]

        at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2014) [!/:na]

Could anybody shed a light on how to use JNDI in an AEM component? 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by joerghoh

the class "com.day.commons.simplejndi.impl.ContextService" is not exported by the Simple JNDI Bundle, thus you cannot consume it in that way.

there are other ways available to validate email adresses, which do not require JNDI, for example here: EmailValidator (Apache Commons Validator 1.6 API)

2 replies

joerghoh
Adobe Employee
joerghohAdobe EmployeeAccepted solution
Adobe Employee
April 28, 2019

the class "com.day.commons.simplejndi.impl.ContextService" is not exported by the Simple JNDI Bundle, thus you cannot consume it in that way.

there are other ways available to validate email adresses, which do not require JNDI, for example here: EmailValidator (Apache Commons Validator 1.6 API)

smacdonald2008
Level 10
April 28, 2019

As Jierg suggests, use a public facing API that AEM exposes.