2 Replies Latest reply on Apr 4, 2006 3:37 PM by starksm64

    Refactoring org.jboss.invocation.* into a remoting project

    starksm64
    starksm64 Mar 1, 2006 3:28 PM

      While I'm refactoring the org.jboss.naming.* package to pull it out of the server package, and a related task is pulling out the detached invoker code from the NamingService into a jmx interceptor. This is just boiler plate proxy factory aspect code that really should already exist and live outside of the server and cluster modules. I talked some to Tom about moving this type of stuff into a remoting project and eventually replacing the legacy invocation stuff with the new remoting transport. How we get this done along with pulling out the ejb3 remoting usage/aop remoting is the subject of this topic.

      • 7764 Views
      • Tags:
        • 1. Re: Refactoring org.jboss.invocation.* into a remoting proje
          tom.elrod Apr 4, 2006 3:13 PM (in response to starksm64)

          Pulling detached invokers and AOP remoting into JBossRemoting is scheduled for Bluto release (JBREM-385 & JBREM-398). Does replacing jndi transport with remoting also need to be included in this release?

          I think jmx remoting should be kept separate from this effort and go under jmx remoting (jsr-160) implementation (basically switching over to use that when complete... which has no end point in sight).

            • Actions
          • 2. Re: Refactoring org.jboss.invocation.* into a remoting proje
            starksm64
            starksm64 Apr 4, 2006 3:37 PM (in response to starksm64)

            Ideally all of the transport stuff should be pulled out of jndi, but doing this for the bootstrap stuff for the naming proxy needs to be done without breaking all of the existing configurations. There is also coupling with ha behavior in the NamingContext that further complicates this. Jerry was working on factoring this out.

            We should have the ability to deploy the naming service without any coupling to transport behaviors. Just need to see how this could be done while supporting the transport related options specified at the InitialContextFactory level.

              • Actions