Tapestry 5
  1. Tapestry 5
  2. TAP5-1078

Refactor the management of ServiceProxyProvider

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 5.1.0.5
    • Fix Version/s: None
    • Component/s: tapestry-ioc
    • Labels:
      None

      Description

      Currently the ServiceProxyProvider/Registry is stored in a static field of SerializationSupport and retrieved via static methods. This approach works fine if Tapestry IoC JAR is located in WEB-INF/lib of an application. Unfortunately this approach is not compatible with OSGi where Tapestry IoC bundle is shared by several bundles, each creating its own Registry. The registry does a SerializationSupport #setProvider() at startup. Starting several Registries inside a JVM it is not possible to make sure that the Registry reference in SerializationSupport is always the same.

      I realized the problem starting two OSGi bundles, each starting its own Registry. When one of these bundles is stopped, its Registry is shut down. In this case we see the following log message:

      25.03.2010 10:47:04,680 # ERROR # org.apache.tapestry5.ioc.internal.SerializationSupport # [SerializationSupport.setProvider] # Setting a new service proxy provider when there's already an existing provider. This may indicate that you have multiple IoC Registries.

      We should refactor the management of ServiceProxyProvider. I think it is sufficient to move the logic of SerializationSupport into InternalRegistry.

        Activity

        Hide
        Howard M. Lewis Ship added a comment -

        What can be done about this? What's really needed is a notification from the servlet container that objects are about to be de-serialized, so that we can store a per-thread object that links the serialized service tokens back to registry. Failing that, this bug may not be fixable.

        Show
        Howard M. Lewis Ship added a comment - What can be done about this? What's really needed is a notification from the servlet container that objects are about to be de-serialized, so that we can store a per-thread object that links the serialized service tokens back to registry. Failing that, this bug may not be fixable.
        Hide
        Bob Harner added a comment -

        Igor, would you agree to closing this issue, or at least lowering it's priority? You didn't respond to Howard's comment a year ago that this may not be fixable.

        Show
        Bob Harner added a comment - Igor, would you agree to closing this issue, or at least lowering it's priority? You didn't respond to Howard's comment a year ago that this may not be fixable.

          People

          • Assignee:
            Unassigned
            Reporter:
            Igor Drobiazko
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development