RE: 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) .....
      }


      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.
               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.

      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