Details

    • Type: Sub-task Sub-task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.0
    • Fix Version/s: 3.0-M1
    • Component/s: None
    • Labels:
      None

      Description

      Nothing worth more than an example:

      Here is the current service method of the SMTPServer:

      public void service( final ServiceManager manager ) throws ServiceException {
      super.service( manager );
      serviceManager = manager;
      mailetcontext = (MailetContext) manager.lookup("org.apache.mailet.MailetContext");
      mailServer = (MailServer) manager.lookup(MailServer.ROLE);
      users = (UsersRepository) manager.lookup(UsersRepository.ROLE);
      dnsServer = (DNSServer) manager.lookup(DNSServer.ROLE);
      }

      We could change it to

      public void service( final ServiceManager manager ) throws ServiceException {
      super.service( manager );
      serviceManager = manager;
      setMailetContext((MailetContext) manager.lookup("org.apache.mailet.MailetContext"));
      setMailServer((MailServer) manager.lookup(MailServer.ROLE));
      setUsersRepository((UsersRepository) manager.lookup(UsersRepository.ROLE));
      setDNSServer((DNSServer) manager.lookup(DNSServer.ROLE));
      }

      and add the above setters.

      This way we can fill dependencies of SMTPServer without using the Serviceable interface and the ServiceManager component.
      Later we'll move the whole service method and Serviceable interface to the specific Avalon extension of the "container-agnostic" SMTPServer.

        Activity

        Hide
        Bernd Fondermann added a comment -

        +1

        Show
        Bernd Fondermann added a comment - +1
        Hide
        Norman Maurer added a comment -

        +1

        Show
        Norman Maurer added a comment - +1
        Hide
        Noel J. Bergman added a comment -

        As long as we're refactoring, I'd like us to look at setting up the appropriate JNDI InitialContext, so that we can lookup the necessary components.

        Show
        Noel J. Bergman added a comment - As long as we're refactoring, I'd like us to look at setting up the appropriate JNDI InitialContext, so that we can lookup the necessary components.
        Hide
        Stefano Bagnara added a comment -

        I really don't like (never heard of projects using that) JNDI for fine grained service/component wiring/configuration.

        I think that using JNDI will give much more power to the services itself and remove power from the container: noone is moving in this direction today.

        If we move to commons-configuration or obix configuration framework then we can store configurations in JNDI/LDAP, but I don't think that the JNDI wiring is good at all.

        As you are a "supporter of the OSGi cause", can you point me some example of how OSGi and JNDI should be used together and link to any project succesfully using the 2 technologies?

        Btw once we'll have SDI objects noone block us from creating an extension of those objects to lookup services in JNDI and call the setters, isn't it true?

        Show
        Stefano Bagnara added a comment - I really don't like (never heard of projects using that) JNDI for fine grained service/component wiring/configuration. I think that using JNDI will give much more power to the services itself and remove power from the container: noone is moving in this direction today. If we move to commons-configuration or obix configuration framework then we can store configurations in JNDI/LDAP, but I don't think that the JNDI wiring is good at all. As you are a "supporter of the OSGi cause", can you point me some example of how OSGi and JNDI should be used together and link to any project succesfully using the 2 technologies? Btw once we'll have SDI objects noone block us from creating an extension of those objects to lookup services in JNDI and call the setters, isn't it true?
        Hide
        Stefano Bagnara added a comment -

        PS: The intent of this issue was not to open a new religious threads about containers and IoC patterns. I would like to do a single small step without too much discussion.

        If we agree that the SDI refactoring is a good step then let's do it: IIRC we discussed a lot of this, and the question was SDI vs CDI, not SDI vs JNDI. The result was that CDI can be easily created extending an SDI object and SDI is more Avalon friendly and easier to apply in our roadmap without early breaking backward compatibility.

        I would like to understand better your OSGi/JNDI ideas, but I think they deserve their own issues, their own wiki pages or their mailing list threads.

        Show
        Stefano Bagnara added a comment - PS: The intent of this issue was not to open a new religious threads about containers and IoC patterns. I would like to do a single small step without too much discussion. If we agree that the SDI refactoring is a good step then let's do it: IIRC we discussed a lot of this, and the question was SDI vs CDI, not SDI vs JNDI. The result was that CDI can be easily created extending an SDI object and SDI is more Avalon friendly and easier to apply in our roadmap without early breaking backward compatibility. I would like to understand better your OSGi/JNDI ideas, but I think they deserve their own issues, their own wiki pages or their mailing list threads.
        Hide
        Bernd Fondermann added a comment -

        Anyone having any objections starting this?
        For me, the JNDI part is a separate task so I would leave this out in the first place.

        Show
        Bernd Fondermann added a comment - Anyone having any objections starting this? For me, the JNDI part is a separate task so I would leave this out in the first place.
        Hide
        Bernd Fondermann added a comment -

        The task is at least 50% completed.

        There are still discussions how mailets and matchers should receive references to needed services and whether or not this should happen through setter injection. This is the part where some setters are missing, while others had been added before already.

        Show
        Bernd Fondermann added a comment - The task is at least 50% completed. There are still discussions how mailets and matchers should receive references to needed services and whether or not this should happen through setter injection. This is the part where some setters are missing, while others had been added before already.
        Hide
        Norman Maurer added a comment -

        we use JSR250 in trunk

        Show
        Norman Maurer added a comment - we use JSR250 in trunk

          People

          • Assignee:
            Norman Maurer
            Reporter:
            Stefano Bagnara
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development