JNDI binding/unbinding error in EAP 6.1.0.Alpha1

[jeff.yuchang]

Hi all,

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).

{code:java}
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.");
             }
         }
     }
}
{code}

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", so here is my question:

In the EAP 6.1.0.Alpha, do we also need to use the internal API, like the ServiceTarget, WritableServiceBasedNamingStore etc, in order to do the JNDI binding from the modules? If not, what API should I use?

Thanks

Jeff

[jaikiran]

Hmm, looks like we broke the compatibility. That method no longer exists. There's a separate method which expects the ServiceName of the owner. I'm not sure why exactly this API was removed (without any deprecation). Can you please file a JIRA for this one please?

[jeff.yuchang]

Done, it is: https://issues.jboss.org/browse/AS7-6877

So, it means I still need to use those two internal APIs, is it right?

Regards

Jeff

[ctomc]

Hi,

you can still use internal api, but difference is that method signature for pushOwner has changed to accept just ServiceName object.

so if you change your code and recompile it against 7.2.0.Final it will work.

or you can still use old API and wait for the fix...

--

tomaz

[jaikiran]

Jeff where and how exactly do you make use of this? Is this some user application or is it part of some subsystem that's developed for AS7?

[jeff.yuchang]

Hi Jaikiran,

It is part of the subsystem, it provides the BPEL service.

Once the BPEL engine starts, it will register itself in the JNDI from the module extension.

Now I use an hard-coded service name thats dedicated for riftsaw.

{code:java}
private static final ServiceName RIFTSAW_SERVICE_NAME = ServiceName.JBOSS.append("RiftSaw");
{code}

And looks like in the previous version, I forgot to popOwner. Anyway, following code is the updated one.

{code:java}
                  try {
                       WritableServiceBasedNamingStore.pushOwner(RIFTSAW_SERVICE_NAME);
                       InitialContext context = new InitialContext();
                       context.bind(name, object);
                   } catch (NamingException e) {
                       LOG.error("Error in binding the object in JNDI.", e);
                   } finally {
                             WritableServiceBasedNamingStore.popOwner();
                   }
{code}

[jaikiran]

Is this in github some place? I'm just curious if you really need this API to work or if we can find some other way around this.

[jeff.yuchang]

It is at: https://github.com/riftsaw/riftsaw/blob/master/engine/src/main/java/org/riftsaw/engine/internal/BPELEngineImpl.java

When we deploy the bpel-console in the AS7 (standalone/deployment) folder, it will access the JNDI to get the BPEL Engine.

Would be glad if we can find other way to not to use the internal API.

Regards

Jeff

[jeff.yuchang]

Looks like I can't just use a random name as following, I need to register it somewhere firstly?

private static final ServiceName RIFTSAW_SERVICE_NAME = ServiceName.JBOSS.append("RiftSaw"); 

I am now getting the NPE:

1. Caused by: java.lang.NullPointerException
2.         at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:81)

Thanks

Jeff

[emmartins]

I explained in JIRA why the change and what to do, but since you added more info about your code here let me guide you into solving this at your side.

The commit I linked in JIRA made similar changes to other subsystems, in concrete if the JNDI bindings depend on the subsystem, instead of a app deployment, then you should capture the MSC service name of the deployable unit you want the bind to be related, and pass it along to that JndiRegistry.

Note that the unbind should not be necessary, the deployable unit stopping should remove it automatically.

[jaikiran]

It looks like in their case, it isn't a deployment unit to which the JNDI entry has to be tied to. Instead it looks like they want to tie it to the BPELEngine process or component, which doesn't belong to a user deployment. I might be wrong though.

[jeff.yuchang]

Jaikiran was right.

It doesn't interact with user deployment at all, it is mainly for our BPEL system use internally.

Regards

Jeff

[jaikiran]

Jeff, in AS7 JNDI entries are tied to the services which own them. What that means, is their lifecycle is controlled via the owning services. Typically when a JNDI entry has to be done for a user deployment, internally AS7 ties that JNDI entry to the ServiceName of the deployment unit and makes the deployment unit service own that entry.

Now in your case it really isn't a user deployment to which the JNDI entry belongs to. But essentially it belongs to some core service offered by the BPEL subsystem. So in such cases, the JNDI entry should exist as long as the BPEL core service exists, which effectively means that the JNDI entry should be tied to the ServiceName of your BPEL core service. Furthermore, when I say "service", I mean an MSC service in AS7. So you'll have to figure out which of your BPEL service is the one which should be owning this JNDI entry. That's essentially part 1 to this problem. The next part is what is the right API to use in this case so that we don't keep breaking the compatibility of such APIs.

[emmartins]

This has nothing to do with user deployments, this is all about naming doing the unbinding automatically.

Let me explain so it may also show up in searchs for similar issues.

Prior to these changes, Naming required that code pushed a service target before doing a bind, and what naming would do is to create the bind MSC service as a child of that service target, so when the service target stopped its childs would stop too. The problem was that this would not work well with component's lifecycles, AS7-6246/AS7-5584 is an example of that. There were other issues and dangers, and this particular use case shows it, Riftsaw was adding the bind service to the container's service target, which means that if Riftsaw forgot to unbind, the bind would only be removed when the container stopped.

After the changes the binding service is always added to the same service target, and do not rely on it to stop. The DU service name is for Naming to keep track of what deployment does such bind, doesn't matter if it a user deployment or subsystem. Each DU has a special service where Naming manages the related bindings, and when the DU stops, that service stops, and it stops all related bindings.

Now we could make life easier for cases like this, and do not require the DU service name to be pushed. What Naming would do in such case is to not control the bind removal, and that is a door I'm not sure we want to open...

--E

[jaikiran]

Eduardo Martins wrote:

The DU service name is for Naming to keep track of what deployment does such bind, doesn't matter if it a user deployment or subsystem.

IMO, it does matter in this case since if there's no deployment unit involved (like in this case, from what I understand), then there's no DU service name which the client code could pass on to the naming subsystem. Essentially what's being said is, the JNDI binding isn't related to a deployment and instead belongs to (perhaps a service installed by) a subsystem.

Eduardo Martins wrote:

Now we could make life easier for cases like this, and do not require the DU service name to be pushed. What Naming would do in such case is to not control the bind removal, and that is a door I'm not sure we want to open...

I think what we need to decide about is the use case where a particular subsystem (which can even be outside of core AS) needs to bind something to JNDI. What are the APIs they are expected to use when:

1) The JNDI entry being bound corresponds to the whole subsystem

2) The JNDI entry being bound corresponds to a deployment unit being handled by that subsystem

Do we require them to use certain APIs for this to work?