6 Replies Latest reply on Nov 13, 2008 11:24 AM by Kevin Conner

    Permanent POJOs?

    David Lloyd Master

      Is there a proper way to install a POJO permanently? as in, it cannot be uninstalled for the life of the JVM? I was just exploring this URLStreamHandlerFactory idea and there doesn't seem to be a good way (short of reflection hackery) to permit lazy loading or unloading of URLStreamHandlers - once one is defined, it's in for good. So exploring the idea further would mean that a POJO that is installed as a URL handler would have to live permanently.

      Is it possible?

        • 1. Re: Permanent POJOs?
          Ales Justin Master

          And don't understand what exactly you mean. :-)

          Install it where?
          Once MC-Kernel is shutdown, all beans are uninstalled == reverted lifecycle invocation.
          What you do during install/uninstall is up to you.

          Perhaps ProfileService with its serialization could help you here,
          saving some contextual state.
          e.g. don't do X since you already did it in previous run

          • 2. Re: Permanent POJOs?
            David Lloyd Master

            Hm, maybe. Perhaps this kind of thing should just be outside the purview of the MC altogether, or perhaps it's just a bad idea in general. I would have liked to provide a mechanism where you could deploy and undeploy URL protocol handlers but I don't think it's going to be possible without introducing an additional API (which I guess isn't out of the question either; it's just not as elegant as I'd like).

            • 3. Re: Permanent POJOs?
              Kevin Conner Master

              OSGi had to introduce an additional API to cover this use case, because of the same issues you are identifying.

              • 4. Re: Permanent POJOs?
                Kevin Conner Master

                I should clarify my last statement.

                OSGi have a service called the URL Handlers service and it is responsible for providing a mediation layer between the JDK classes and any dynamic handlers which may be registered.

                The service handles two aspects, IIRC, the URLStreamHandlers used through URL and the ContentHandlers used through URLConnection. Both of these classes cache any handlers discovered and therefore prevent them from being modified dynamically.

                To get around this restriction OSGi will register proxies on behalf of the ContentHandlers and URLStreamHandlers and these proxies are responsible for delegating to the active handlers services or responding with appropriate faults.

                I believe this is the issue you are facing, apologies if it is not.

                There should be more details in the OSGi specs and I can dig them out if necessary.

                • 5. Re: Permanent POJOs?
                  David Lloyd Master

                  Yup, this is the basic issue. As it happens, we've hacked our way past it for now. But yeah I think the proxy notion is the way to go (eventually). The problem I had was that the actual handlers implement all protected methods, so unless you use reflection or similar tricks, you can't really proxy to another implementation. So I figure that we could create an interface which pluggable URL handlers must implement, and proxy to that. Someday. :-)

                  • 6. Re: Permanent POJOs?
                    Kevin Conner Master

                     

                    "david.lloyd@jboss.com" wrote:
                    So I figure that we could create an interface which pluggable URL handlers must implement, and proxy to that. Someday. :-)


                    This is precisely what OSGi have done, created a new interface which reflects the URLStreamHandler methods and then the proxy can invoke them directly. :)