Incompatible change in jboss-deployers

[thomas.diesler]

jboss-deployers-spi-2.2.0.Alpha5 comes with  org.jboss.deployers.spi.classloading.DeploymentMetaData

which has moved from org.jboss.deployers.plugins.classloading.DeploymentMetaData in 2.2.0.Alpha4

A change like this means that jbosgi won't run anymore in target containers that use 2.2.0.Alpha4. This would be AS-6.0.0.M3

This effectivly means, that jbosgi does not run in any target container, but AS/trunk which is a moving target.

What you should do instead, is deprecate the old interface. The deprecated interface should extend the new one. This would provide a migration path.

In our confcall, we can discuss this backward compatibility issue.

[bosschaert]

So I guess this means that we can't do a JBoss-OSGi release until AS-6.0.0.M4 is out?

Anyone an idea when we can expect that?

[thomas.diesler]

MC cant break JBOSGi compatibilty like this (i.e. remove support for any released AS version)

Instead, AS/trunk should get a 2.2.0.Alpha6 which restores the old interface, so jbosgi continues to run in AS-6.0.0.M3

[thomas.diesler]

This issue also breaks the startup of the osgi profile in AS trunk

bin/run.sh -c osgi

09:09:39,070 ERROR [AbstractKernelController] Error installing to Instantiated: name=OSGiDeploymentMetaDataDeployer state=Described: java.lang.NoClassDefFoundError: org/jboss/deployers/plugins/classloading/DeploymentMetaData
    at org.jboss.osgi.framework.deployers.OSGiDeploymentMetaDataDeployer.<init>(OSGiDeploymentMetaDataDeployer.java:47) [:1.0.0.Alpha4]
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [:1.6.0_20]
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) [:1.6.0_20]
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) [:1.6.0_20]
    at java.lang.reflect.Constructor.newInstance(Constructor.java:513) [:1.6.0_20]
    at org.jboss.reflect.plugins.introspection.ReflectionUtils.newInstance(ReflectionUtils.java:154) [jboss-reflect.jar:2.2.0.Alpha5]
    ...
Caused by: java.lang.ClassNotFoundException: org.jboss.deployers.plugins.classloading.DeploymentMetaData from BaseClassLoader@12b0f0ae{vfs:///home/tdiesler/git/jbossas/build/target/jboss-6.0.0-SNAPSHOT/server/osgi/deployers/osgi.deployer}
    at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:480) [jboss-classloader.jar:2.2.0.Alpha5]
    at java.lang.ClassLoader.loadClass(ClassLoader.java:248) [:1.6.0_20]

[alesj]

What about if you create this class yourself in OSGi project?

And then just delegate the work to the original (the one I moved).

[alesj]

What about if you create this class yourself in OSGi project?

You can use this deployer, which knows how to choose the right DeploymentMetaData class:

package org.jboss.osgi.framework.deployers;

import java.lang.reflect.Method;

import org.jboss.deployers.spi.DeploymentException;
import org.jboss.deployers.spi.deployer.DeploymentStages;
import org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer;
import org.jboss.deployers.structure.spi.DeploymentUnit;
import org.jboss.osgi.framework.metadata.OSGiMetaData;

/**
 * Hack deployment metadata deployer to hack around Deployers DMD class move.
 */
public class HackDeploymentMetaDataDeployer extends AbstractSimpleRealDeployer<OSGiMetaData>
{
   private static Class<?> dmdClass;

   static
   {
      ClassLoader cl = HackDeploymentMetaDataDeployer.class.getClassLoader();
      try
      {
         dmdClass = cl.loadClass("org.jboss.deployers.plugins.classloading.DeploymentMetaData");
      }
      catch (ClassNotFoundException e)
      {
         try
         {
            dmdClass = cl.loadClass("org.jboss.deployers.spi.classloading.DeploymentMetaData");
         }
         catch (ClassNotFoundException cnfe)
         {
            throw new RuntimeException("Cannot load DeploymentMetaData class", cnfe);
         }
      }
   }

   public HackDeploymentMetaDataDeployer()
   {
      super(OSGiMetaData.class);
      addInput(dmdClass);
      addOutput(dmdClass);
      setStage(DeploymentStages.POST_PARSE);
      setTopLevelOnly(true);
   }

   public void deploy(DeploymentUnit unit, OSGiMetaData deployment) throws DeploymentException
   {
      if (unit.isAttachmentPresent(dmdClass))
         return;

      try
      {
         Object deploymentMetaData = dmdClass.newInstance();
         unit.addAttachment(dmdClass.getName(), deploymentMetaData);
         Method setLazyResolve = dmdClass.getMethod("setLazyResolve", boolean.class);
         setLazyResolve.invoke(deploymentMetaData, true);
      }
      catch (Exception e)
      {
         throw DeploymentException.rethrowAsDeploymentException("Error handling depoyment metadata", e);
      }
   }
}

[thomas.diesler]

Yes, that works - good idea (f)