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