[jboss-jira] [JBoss JIRA] (WFLY-963) NoSuchMethodError pushOwner(ServiceTarget, ServiceName)

[Eduardo Martins (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771987#comment-12771987 ] 

Eduardo Martins edited comment on WFLY-963 at 5/3/13 11:49 AM:
---------------------------------------------------------------

Jeff was able to solve his case, but the workaround used was to adapt WritableServiceBasedNamingStore logic from (un)bind, IMHO we should have an API for modules/subsystems, possible options are:

1) Accept bindings done without WritableServiceBasedNamingStore.pushOwner(), i.e. WritableServiceBasedNamingStore bind() and unbind() would accept and understand that if owner not set then the op is related to a unmanaged bind, i.e. unbind not done automatically. This could open the door for bugs based on developer forgetting to use pushOwner() when they should, but a good thing of this solution is that the API is just the standard JNDI, and no particular properties need to be set, which means code could be easily ported to somewhere else. In this case there is no chance of defining a specific service target to add the binding service, so we would have to use the naming store's service, but then we are talking about unmanaged.
 
2) Provide an alternative JNDI context impl, available by passing config properties on new InitialContext(properties). No doors open for misusage, dependency only on JNDI api, but needing special properties is not much different than having a proprietary API. No chance of defining a specific service target too.
 
3) Provide a proprietary API, something like WritableServiceBasedNamingStore.unmanagedBind(String name, Object value). A solution that clearly defines the functionality with little chance of misusage, which could even allow ops targeting a specific service target, but there is the dependency on AS Naming, so not much better than using MSC's BinderService.
 
>From the AS Naming developer point of view I'm more into 3) but standard JNDI api failing like in this issue could make 1) more desirable, even if more dangerous.
                
      was (Author: emmartins):
    Jeff was able to solve his case, but the workaround used was to adapt WritableServiceBasedNamingStore logic from (un)bind, IMHO we should have an API for modules/subsystems, possible options are:

1) Accept bindings done without WritableServiceBasedNamingStore.pushOwner(), i.e. WritableServiceBasedNamingStorethis's bind() and unbind() would understand that if owner not set then the op is related to a unmanaged bind, i.e. unbind not done automatically. This could open the door for bugs based on developer forgetting to use pushOwner() when they should, but a good thing of this solution is that the API is just the standard JNDI, and no particular properties need to be set, which means code could be easily ported to somewhere else. In this case there is no chance of defining a specific service target to add the binding service, so we would have to use the naming store's service, but then we are talking about unmanaged.
 
2) Provide an alternative JNDI context impl, available by passing config properties on new InitialContext(properties). No doors open for misusage, dependency only on JNDI api, but needing special properties is not much different than having a proprietary API. No chance of defining a specific service target too.
 
3) Provide a proprietary API, something like WritableServiceBasedNamingStore.unmanagedBind(String name, Object value). A solution that clearly defines the functionality with little chance of misusage, which could even allow ops targeting a specific service target, but there is the dependency on AS Naming, so not much better than using MSC's BinderService.
 
>From the AS Naming developer point of view I'm more into 3) but standard JNDI api failing like in this issue could make 1) more desirable, even if more dangerous.
                  
> NoSuchMethodError pushOwner(ServiceTarget,ServiceName)
> ------------------------------------------------------
>
>                 Key: WFLY-963
>                 URL: https://issues.jboss.org/browse/WFLY-963
>             Project: WildFly
>          Issue Type: Bug
>          Components: Naming
>            Reporter: Jeff Yu
>            Assignee: Eduardo Martins
>
> In the JBoss AS-7.1.1.Final, I used the following code to do the JNDI binding/unbinding from the modules (not deployed in the deployment folder).
>  
>  
> public class JndiRegistry {
>  
>      private static final Log LOG= LogFactory.getLog(JndiRegistry.class);
>  
>      public static void bindToJndi(String name, Object object) {
>          ServiceTarget serviceTarget = CurrentServiceContainer.getServiceContainer();
>          if (serviceTarget != null) {
>             WritableServiceBasedNamingStore.pushOwner(serviceTarget);
>              try {
>                  InitialContext context = new InitialContext();
>                  context.bind(name, object);
>              } catch (NamingException e) {
>                  LOG.error("Error in binding the object in JNDI.");
>              }
>          }
>      }
>  
>      public static void unbindFromJndi(String name){
>          ServiceTarget serviceTarget = CurrentServiceContainer.getServiceContainer();
>          if (serviceTarget != null) {
>              WritableServiceBasedNamingStore.pushOwner(serviceTarget);
>              try {
>                  InitialContext context = new InitialContext();
>                  context.unbind(name);
>              } catch (NamingException e) {
>                  LOG.error("Error in unbinding the object from JNDI.");
>              }
>          }
>      }
>  
> }
>  
>  
>  
> With the EAP 6.1.0.Alpha, I am getting the error of "
> Caused by: java.lang.NoSuchMethodError: org.jboss.as.naming.WritableServiceBasedNamingStore.pushOwner(Lorg/jboss/msc/service/ServiceTarget;[Lorg/jboss/msc/service/ServiceName;)V",

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira