Re: RE: Admin API and GUI

See inline
  ----- Original Message ----- 
  From: Tim Anderson 
  To: openjms-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
  Sent: Tuesday, July 29, 2003 6:34 AM
  Subject: RE: [openjms-developer] RE: Admin API and GUI


  +1 to removing the boolean statuses as well.
  All of those methods should throw an exception on failure.
    -----Original Message-----
    From: openjms-developer-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:openjms-developer-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org]On Behalf Of Tim Anderson
    Sent: Tuesday, 29 July 2003 4:27 PM
    To: Knut at work; openjms-developer
    Subject: [openjms-developer] RE: Admin API and GUI


    See inline
      -----Original Message-----
      From: Knut at work [mailto:knut.lerpold-Y0ltV1YbkABUXjr8k6HNnAC/[email protected]]
      Sent: Tuesday, 29 July 2003 6:56 PM
      To: [email protected]
      Subject: Re: Admin API and GUI



        ----- Original Message ----- 
        From: Tim Anderson 
        To: openjms-developer ; Knut at work 
        Sent: Tuesday, July 29, 2003 4:26 AM
        Subject: RE: Admin API and GUI


        Thanks Knut.

        I'll commit the changes but I think the new admininistration API needs to be 
        thought out more. 
        We can safely deprecate the existing admin API  - you're effectively working 
        with a clean slate so you don't need to be tied to the existing method 
        implementations. If need be, we can also add new JMSException subclasses
        to indicate the reasons for failures. Some of the existing methods confusingly
        throw JMSException but also return a boolean status.

        Some of the methods should not throw JMSException at all! User for instance.
        What about a own exception eg. AdminException??
        [tima] Yep - thats fine. The advantage of subclassing JMSException is that
                  you don't have too many throw clauses which make the API unwieldy to use. 
                  It just encourages people to catch Exception instead.

        Also connect() disconnect() - connect() need to be able to throw JMSSecurityEx
        but all other exeptions have somthing to do with the connection not JMS.

        [tima] I would drop the Connect interface. AdminConnectionFactory would then
                 change to

        public class AdminConnectionFactory {

           public AdminConnection connect(String url, String username, String password)  
                throws JMSSecurityException, AdminException;

           /**
             *
             * @deprecated
             */
           public JmsAdminServerIfc create(String url) .....
        }

        [knut] 
        Personaly I prefer the API to contain the connect(), disconnect() insted of having the the connect() 
        delivering the API and then only have close() (or disconnect() ) represented inside the API.
        Anyway this is not a big deal :-)  But if we do it like you described I suggest that we rename connect() to createConnection().



        Im not very found of boolean statuses for methods doing add/change/remove 
        I prefer either void or that they return the Object the are working with.
        All other 'returns' are Exceptions eg. add of a duplicate object is a 
        Exception not a false.

        In particular, I don't see the advantage in separating the JmsAdminServerIfc
        into AdminConnection, MonitorConnection and SystemConnection.

        My intention behind this was to separate according to Acl. 
        To be able to use Admin you must be eg. Administrator
        To be able to use MonitorConnection (only read access) it is mabe enough to have AdminReadOnly.....  
        Also I find it possible to e.g. write a stand alone appl. to monitor the system.
        [tima] This can be handled within the AdminConnection itself. If a user attempts to 
                  access an object they are not authorised to use, it would throw JMSSecurityException.

        I would prefer AdminConnection to be the main interface - this would
        provide access to destination, security, and server management objects.

        E.g:
          AdminConnectionFactory - create an AdminConnection.
          AdminConnection - provides access to Destinations, Security, and Server
                                      objects.
          Destinations        - topic and queue management.

          Server                 - server management. Probably only a single method
                                      for the moment, i.e shutdown()
        This Is this equal to what I called SystemConnection so we agree on this.

          Security              - user, and in future, ACL management

        I agree on the separation in Destination/Security when it comes to how to build the GUI.
        But as a Interface this looks like subinterfaces of what I called AdminConnection.
        Reason: Needs the same accesslevel and I likely the user will need both interfaces in 
        the same application. 
        [tima] With the separation you are proposing, an application potentially needs to
                 establish three authenticated connections to the server, to perform administration
                 functions. The alternative approach above only requires single sign on,
                 with the expectation that future ACL management will prevent unauthorised
                 operations.

        Also, it would be nice if in future the code you submit followed coding conventions ;)

        Of course, but where do I find the conventions??
        [tima] Good point. I removed them with the expectation I would have the maven build
                 up and running by now - as no-one ever reads coding convention docs,
                 its must easier if the build process reports on violations.

        [knut]
        +1 for having the build report violations.

                 Maven runs checkstyle as part of its report generation process. 
                 You can see the current results here: http://openjms.sourceforge.net/checkstyle-report.html
                 As you can see, there's a lot of cleaning up to do. My aim is to not
                 introduce new violations, and gradually clean up the existing ones.

         
        [knut]
        Could you provide the checkstyle-config file?

        I'm aiming to have the maven build env complete in a week or so - one of the nice
        things it does is include checkstyle reports, so its easy to see what needs to be 
        changed.

        Regards,

        Tim


          -----Original Message-----
          From: Knut at work [mailto:knut.lerpold-Y0ltV1YbkABUXjr8k6HNnAC/[email protected]]
          Sent: Tuesday, 29 July 2003 3:14 AM
          To: [email protected]
          Subject: Admin API and GUI


          All src. is based on the latest version from the CVS.

          Have made only minimum requirement on the GUI since Im going to rewrite this during this autumn. 
          Have not impl. Logon for offlineConnection


          Classes that have changed name;

          AdminConnection  --> AbstractAdminConnection  --  needed the AdminConnection for the new connection-interface
          OpenJMSDestination  -->  OpenJMSObject  -- needed this for OpenJMSUser as well, thought the name was a bit misleading.

          New classes;
          CreateLogonDialog
          CreateUserDialog
          ChangePasswordDialog
          OpenJMSUser
          OpenJMSObject   <--- replace OpenJMSDestination
          AbstractAdminConnection  <--- replace AdminConnection

          I have rewritten how to obtain administred connections:
          classes;
          ConnectionFactory

          interfaces:
          Connect            <--- contains only connect() and disconnect() is package-private.
          AdminConnection    <--- 
                                              ----   Replaces the old JmsAdminServerIfc    
          MonitorConnection  <--- 
          SystemConnection   <--- Not impl. to be used to configure the server: cache, log, acceptors etc.

          Have deprecated JmsAdminServerIfc and AdminConnectionFactory


          Modified classes;
          see Zip-file.
          Have been trying to run a diff against the cvs but the operation gets canceled evry time so Im afraid you will have to do that .....


          K