7 Replies Latest reply on Jul 28, 2008 1:55 PM by pmuir

    Seam SPI

    pmuir

      [Posting here as Seam uses mailing lists for development discussions and the Seam users forum isn't hosted on jboss.org, please move if it is the incorrect place]

      Why isn't this in the forums?


      Because I was asking Stan's opinion on something before taking it to a wider audience.

      Pete, your solution is a joke.
      Why does an integration api require you
      to replace classes?


      Because I don't think want users to have to deploy jboss-seam.jar and jboss-seam-spi.jar to their app server of choice.

      1) Define the spi in jboss-seam.jar
      They should be interfaces (the i in spi)


      Exactly. This is what I want to do.

      2) Provide a default implementation in jboss-seam.jar
      (if necessary) with a mechanism to override the
      implementation class for each integration point,
      e.g. system properties or service provider mechanism


      Yes, currently we provide two options for specifying extensions, firstly via system properties, secondly via a .properties file in META-INF/ for scenarios like this.

      3) We can implementation those interfaces in a different
      way for jboss-x.y.z or somebody else can do it
      for another-environment-1.2.3


      Yes.

      However AFAIK JBoss isolated classloading won't allow this simple a solution.

      jboss-seam.jar is deployed in ${project}.ear/lib/jboss-seam.jar, with isolated classloading turned on. Therefore /default/deploy/lib/jboss-seam-jbas5.jar wouldn't be able to load the interfaces defined in jboss-seam.jar deployed inside the ear.

      And a quick test shows this to be the case. I added the interface Foo to jboss-seam.jar, added a jar /default/deploy/lib/jboss-seam-jbas5.jar with the class FooImpl implements Foo, and then tried to instantiate FooImpl using Foo foo = (Foo) Class.forName("org.jboss.seam.as5.FooImpl").newInstance(); when Seam deploys. As expected, I get a NCDFE.

      org.jboss.seam.InstantiationException: Could not instantiate Seam component: fooTest
       at org.jboss.seam.Component.newInstance(Component.java:2103)
       at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
       at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
       at org.jboss.seam.contexts.ServletLifecycle.endInitialization(ServletLifecycle.java:95)
       at org.jboss.seam.init.Initialization.init(Initialization.java:630)
       at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.java:34)
       at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3856)
       at org.apache.catalina.core.StandardContext.start(StandardContext.java:4361)
       at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:790)
       at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:770)
       at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:553)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:296)
       at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
       at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
       at org.apache.catalina.core.StandardContext.init(StandardContext.java:5312)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:296)
       at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
       at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
       at org.jboss.web.tomcat.service.TomcatDeployer.performDeployInternal(TomcatDeployer.java:301)
       at org.jboss.web.tomcat.service.TomcatDeployer.performDeploy(TomcatDeployer.java:104)
       at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:375)
      
       at org.jboss.web.WebModule.startModule(WebModule.java:83)
       at org.jboss.web.WebModule.startService(WebModule.java:61)
       at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
       at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
       at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
       at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
       at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
       at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
       at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
       at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
       at $Proxy0.start(Unknown Source)
       at org.jboss.system.ServiceController.start(ServiceController.java:417)
       at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
       at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
       at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
       at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
       at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
       at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
       at $Proxy44.start(Unknown Source)
       at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:466)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
       at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
       at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
       at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
       at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
       at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
       at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
       at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:87)
       at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
       at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
       at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
       at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
       at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
       at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
       at $Proxy45.start(Unknown Source)
       at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
       at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
       at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
       at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
       at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
       at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
       at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
       at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
       at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
       at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
       at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
       at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
       at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
       at $Proxy9.deploy(Unknown Source)
       at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
       at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
       at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
       at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
       at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
       at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
       at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
       at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
       at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
       at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
       at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
       at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
       at $Proxy0.start(Unknown Source)
       at org.jboss.system.ServiceController.start(ServiceController.java:417)
       at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
       at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
       at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
       at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
       at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
       at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
       at $Proxy4.start(Unknown Source)
       at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
       at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
       at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
       at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
       at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
       at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
       at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
       at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
       at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
       at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
       at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
       at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
       at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
       at $Proxy5.deploy(Unknown Source)
       at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
       at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
       at org.jboss.Main.boot(Main.java:200)
       at org.jboss.Main$1.run(Main.java:508)
       at java.lang.Thread.run(Thread.java:613)
      Caused by: java.lang.RuntimeException: exception invoking: create
       at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:136)
       at org.jboss.seam.Component.callComponentMethod(Component.java:2208)
       at org.jboss.seam.Component.callCreateMethod(Component.java:2131)
       at org.jboss.seam.Component.newInstance(Component.java:2091)
       ... 141 more
      Caused by: java.lang.reflect.InvocationTargetException
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
       at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
       at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
       at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:31)
       at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
       at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:42)
       at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
       at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
       at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
       at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
       at org.jboss.seam.FooTest_$$_javassist_0.create(FooTest_$$_javassist_0.java)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
       at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:126)
       ... 144 more
      Caused by: java.lang.NoClassDefFoundError: org/jboss/seam/Foo
       at java.lang.ClassLoader.defineClass1(Native Method)
       at java.lang.ClassLoader.defineClass(ClassLoader.java:675)
       at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
       at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
       at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
       at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
       at java.security.AccessController.doPrivileged(Native Method)
       at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
       at org.jboss.mx.loading.RepositoryClassLoader.findClassLocally(RepositoryClassLoader.java:682)
       at org.jboss.mx.loading.RepositoryClassLoader.findClass(RepositoryClassLoader.java:662)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:316)
       at org.jboss.mx.loading.RepositoryClassLoader.loadClassLocally(RepositoryClassLoader.java:200)
       at org.jboss.mx.loading.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:131)
       at org.jboss.mx.loading.LoadMgr3.nextTask(LoadMgr3.java:399)
       at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:527)
       at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:415)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
       at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
       at java.lang.Class.forName0(Native Method)
       at java.lang.Class.forName(Class.java:164)
       at org.jboss.seam.FooTest.create(FooTest.java:17)
       ... 165 more


      Any suggestions

      >> On Thu, 2008-07-17 at 09:25 -0400, Stan Silvert wrote:
      >> I assume you mean /default/lib/jboss-seam-spi.jar and not
      >> /default/deploy/lib/jboss-seam-spi.jar.

      Yes.

      >> I'm not sure if it's a good idea to rely on classloading order if you
      > can avoid it. That always led to support issues in 3.x and 4.x.

      >> Adrian would know the best solution for JBoss 5. I would say that there
      >> are probably some cool new features for this, but Adrian doesn't do cool.

      > Stan

      >Pete Muir wrote:
      >>All this stuff to make Seam work on JBoss 5 (needing to call JBoss
      >>specific methods) makes me think we need an SPI for Seam, so that the
      >>relevant code can live in JBoss 5, not Seam.
      >>
      >>However, I don't want to end up having to deploy jboss-seam.jar and
      >>jboss-seam-spi.jar in other app servers, so jboss-seam.jar will need to
      >>include the jboss-seam-spi.jar classes. So, we need to make sure the
      >>JBoss classloader always loads the classes from
      >>/default/deploy/lib/jboss-seam-spi.jar before the ones from
      >>jboss-seam.jar. IIRC this should work. Do you know?

      >>Best,


        • 1. Re: Seam SPI
          pmuir

          Actually, I tested this on AS 4.2.2 but I can't see how the isolated classloading behaviour can be different on AS5

          • 2. Re: Seam SPI

             

            "pete.muir@jboss.org" wrote:

            And a quick test shows this to be the case. I added the interface Foo to jboss-seam.jar, added a jar /default/deploy/lib/jboss-seam-jbas5.jar with the class FooImpl implements Foo, and then tried to instantiate FooImpl using Foo foo = (Foo) Class.forName("org.jboss.seam.as5.FooImpl").newInstance(); when Seam deploys. As expected, I get a NCDFE.


            That's pretty obvious. If you have a scoped jboss-seam.jar
            then something outside the deployment can't see those classes
            except using dynamic classloading, so it isn't going to work for imports.

            Or put another way, if you had two wars with jboss-seam.jar (possibly different
            versions of seam) which version of the interfaces
            should the jboss-seam-jbas5.jar classes use? ;-)

            The old solution would be to put the interfaces in server/default/lib
            and then add a filter to the war deployment such that it doesn't load the
            interfaces from the scoped war.
            But this leaks a single version of the seam api into the shared classloader scope
            of all applications.

            With the new deployers in JBoss5, one possible solution
            is to automatically include the integration classes to the web-app's
            classpath when you detect it is a seam deployment.
            (It could even be different based on the version of seam).

            e.g. pseudo code:
            public class SeamIntegrationDeployer extends AbstractSimpleVFSRealDeployer<JBossWebMetaData>
            {
             /** Location of jboss-seam-jbas5.jar */
             private URL seamIntegrationURL;
            
             public SeamIntegrationDeployer()
             {
             // We only look at wars
             super(JBossWebMetaData.class);
            
             // We have to run before the classloading is setup
             setStage(DeploymentStages.POST_PARSE);
             }
            
             public URL getIntegarionURL()
             {
             return seamIntegrationURL;
             }
            
             public void setIntegrationURL(URL url)
             {
             this.seamIntegrationURL = url;
             }
            
             @Override
             public void deploy(VFSDeploymentUnit unit, JBossWebMetaData metaData) throws DeploymentException
             {
             if (isSeamDeployment(unit))
             {
             VirtualFile seamIntegration = VFS.getVFS(seamIntegrationURL).getRoot();
             unit.addClassPath(seamIntegration);
             }
             }
            
             protected boolean isSeamDeployment(VFSDeploymentUnit unit)
             {
             // ??? WEB-INF/jboss-seam.xml
             return unit.getMetaDataFile("jboss-seam.xml") != null;
             }
            }
            
            jboss-seam-integration-beans.xml
            
            <deployment xmlns="urn:jboss:bean-deployer:2.0">
            
            
             <bean name="SeamIntegrationDeployer" class="org.jboss.xxx.SeamIntegrationDeployer">
            
             <!-- Something like ???? outside the hot deploy folder -->
             <property name="integrationURL">${jboss.home.url}/integration/seam/jboss-seam-as5.jar</property>
             </bean>
            </deployment>
            


            NOTE: the integration jar lives outside the hot deployment directories
            and gets included directly into the classpath of the wars
            when you detect a seam deployment.

            • 3. Re: Seam SPI
              pmuir

               

              "adrian@jboss.org" wrote:
              Or put another way, if you had two wars with jboss-seam.jar (possibly different
              versions of seam) which version of the interfaces
              should the jboss-seam-jbas5.jar classes use? ;-)


              Yup, this was where my comprehension of the problem had got to.

              With the new deployers in JBoss5, one possible solution
              is to automatically include the integration classes to the web-app's
              classpath when you detect it is a seam deployment.
              (It could even be different based on the version of seam).


              Ok, this sounds like a good solution. We'll try to get something working like it.

              Thanks Adrian.

              • 4. Re: Seam SPI

                 

                "adrian@jboss.org" wrote:

                With the new deployers in JBoss5, one possible solution
                is to automatically include the integration classes to the web-app's
                classpath when you detect it is a seam deployment.
                (It could even be different based on the version of seam).


                A better solution (not as hacky) with JBoss 5 would be if
                web-apps used the OSGi style classloading to import jboss seam
                (but this is some way in the future at the moment).

                public class SeamIntegrationDeployer extends AbstractSimpleVFSRealDeployer<JBossWebMetaData>
                {
                 public SeamIntegrationDeployer()
                 {
                 // We only look at wars
                 super(JBossWebMetaData.class);
                
                 // We have to run before the classloading is setup
                 setStage(DeploymentStages.DESCRIBE);
                
                 // We modify the classloading "imports"/requirements
                 addInput(ClassLoadingMetaData.class);
                 setOutput(ClassLoadingMetaData.class);
                 }
                
                 @Override
                 public void deploy(VFSDeploymentUnit unit, JBossWebMetaData metaData) throws DeploymentException
                 {
                 ClassLoadingMetaData clmd = unit.getAttachment(ClassLoadingMetaData.class);
                 List<Requirements> reqiurements = clmd.getRequirements();
                 ModuleRequirement seamModule = hasSeamModuleRequirement(requirements);
                
                 // If we are importing seam then import the jboss integration at the same version
                 if (seamModule != null)
                 {
                 ClassLoaderMetaDataFactory factory = ClassLoaderMetaDataFactory.getInstance();
                 requirements.add(factory.createRequireModule("jboss-seam-integration"), seamModule.getVersion);
                 }
                 }
                


                • 5. Re: Seam SPI
                  alesj

                  I've created (but not yet tested) Adrian's deployers suggestions in more abstract way + adding few real/useful impls:
                  - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/deployers-vfs/src/main/org/jboss/deployers/vfs/plugins/classloader/

                  I also created new jboss-seam-int subproject:
                  - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-seam-int/trunk/

                  I'll have a look how can we push some MC notion all the way down to ServletContext::attributes,
                  so that Seam can actually get a hold of underlying MC beans,
                  e.g. JNDIPolicy that is currently used in AS5 instance.

                  • 6. Re: Seam SPI
                    alrubinger

                     

                    "alesj" wrote:
                    I'll have a look how can we push some MC notion all the way down to ServletContext::attributes,
                    so that Seam can actually get a hold of underlying MC beans,
                    e.g. JNDIPolicy that is currently used in AS5 instance.


                    In this isolated case with Seam and JNDI Names, might make more sense to instead of exposing the metadata decorated w/ JNDI Policy, to instead publish the endpointMap created by the MappedReferenceMetadataResolverDeployer (which has already gone through the task of linking endpoints to target JNDI names). This would give Seam the same dependencies used by the components themselves.

                    S,
                    ALR

                    • 7. Re: Seam SPI
                      pmuir

                      Some ideas Ales and I had:

                      *Default some deployment descriptors if it's a Seam project
                      + ejb-jar.xml (automatically add the SeamInterceptor to all EJBs)
                      + jboss-app.xml (automatically enable classloader isolation, base loader repository name on ear name)
                      + web.xml (automatically add the seam servlet listener, seam resource servlet and seam filter, add the faces servlet)
                      + faces-config.xml (automatically add Facelets view handler if it's on the classpath
                      + Of course, to override any of this you just deploy the file as normal

                      * Ability to automatically discover JNDI name (as discussed with ALR)

                      * Install VFS based scanner, with access to MC annotation database (don't have to scan classes twice!)