RE: Admin API and GUI

I've committed the changes as is, but I would like to see
modifications as described previously.

One thing to note is that with the current implementation,
it is still possible to invoke admin API methods with
an unauthenticated connection, simply by not invoking
connect().
This needs to be changed so that the admin connection
identifier is submitted with each admin request -
the server can verify this against the list of authenticated
admin connections before performing any operation.

Regards,

Tim
  -----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??

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

    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.

    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.

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

    Of course, but where do I find the conventions??
    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