Error: Macro BackLinksMenu(None) failed

compressed data is corrupt

Error: Macro TicketQuery(summary=UNPLANNED_APP_CLIENT_RESOURCES_R0, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|) failed

current transaction is aborted, commands ignored until end of transaction block

Analysis

^{(Give as much as possible of the needed information for designing and implementing the task in the following sections.)}

Overview

• The goal is to move as close as possible for one week, to what we want for the user to be able to do with server resources inside the application. Please view the analysis in GROUP_APP_SERVER_RESOURCE_ACCESS_R0 to achieve more global vision for this task.
• There should be palette (server palette) that will allow the user to chose (add, remove, edit the current account) a server account and then connect to it.
  • Show status (connected, disconnected, connecting etc.) of a server
• Also a list of available resources for the selected server should present.
  • It will be nice if we could manipulate this list (or tree, or whatever comes up) of resources in the same manner as we do inside resource palette

Task requirements

• Create prototype of server palette
  • Provide manipulation over the list with server accounts
    • To add, remove or edit the available servers.
    • User names and passwords
    • Persist the server accounts in some configuration file
  • Make available connection to the server
    • Only as anonymous user at this point (until there is some security for the server)
  • After the user is connected show a list of available resources
    • At this revision no sub resources will be shown. Only a first level resources.
    • No meta data will be shown, only the name of the resource(book)(for now)
    • No filters at this revision
    • The user won't be able(for now) to do the following
      • Add resource(book)
      • Remove resource
      • Rename resource
  • Provide some aspects of the server synchronization
    • Some handling and notification should be considered if connection to server is closed, drop or some other similar situation occurs.

Task result

• The result should be source code

Implementation idea

Palette sketch

Related

GROUP_APP_SERVER_RESOURCE_ACCESS_R0

How to demo

• Start the application
• Go to resource palette and connect to the server
• Focus(Show) the list of available resources on the server and open one
• Edit and save the resource on the server via the app (add frame or page or something)
• Disconnect from server and show that user cannot manipulate and view this resource anymore.
• Show adding of new server, deleting of one and editing.
• Show that accounts are available after restarting the application.

Design

Redesign Resources

• We need to redesign the Account pro object. As the model is now based on base model ResourceR4 module we need

AccountR4 and AccountH to present accounts.

• For persisting sjrb format will be used
• Due to some bugs in FileEntryManager persistence may fail.

Redesign AccountManager

The AccountManager class may be dropped and all the functionality which it provides may be in the ConnectionsPalette.

Create the UI

• Icons for connected/disconnected will be added.
• To be able to add items in the ListPalette a custom ListCellRenderer should be implemented.
• Icons for add/remove/edit server buttons will be created.

Server Logging

• In order server to be logged from custom source but not from the logging facade class some changes on the logging are needed.
• We need to change the LogEntry source. It wont be a stack trace element but a string which will be by default toString of the Starck trace element. Old functionality will be saved, but also extended for our needs.

Mighty Class loader

• A mighty class loader is needed in order the ClassPersister to load classes throughout the modules.
• The easy way to solve this is to implement a Mighty class loader which is felix dependent.
• It will go through the modules and gets their activators (it is possible if we have access to the felix impl classes). After we have the activators we will have their class loaders and can delegate to them.
• The only specific think here is that every module which declares a class which should be loaded through ClassPersister must have a BundleActivator. It may be a dummy one if no extensions/extensions-points are needed.
• This mighty class loader will be registered as system property by the launcher of true editions. and can be used by the persister.

Persistence for keys

• Some auto actions need use keys from the resourceR4 model classes. When they are used for example just like

  changer.setRaw(ResourceR4.KEY_KIND);
  

  it is ok. The key is not becoming a part of the auto action class's body. But when a method of the key is called, for exampple

  changer.setRaw(StyledElement.KEY_BORDER_INSETS.getLocked(), input);
  

the key will be part of the class's body and will have to be persisted.

• key persister will be implemented which uses the resource info providers.
• It will persist only keys form the model (declared in the ResourceR4 classes or the interfaces they are implementing)
• MetaKeys will not be persisted. The must be used outside of the auto actions, or find out a way to persist them in other task.
• UndefindedKeys are special kind of keys that are persisted in different way, they are used by the remote resource model and internally by the ResourceModelChanger. They will still be persisted in the old way and must not be used in the auto action implementations

Implementation

The imp]ementation was done by the design and is in the wrong named branch branches/private/tsachev/GROUP_APP_SERVER_RESOURCE_ACCESS_R0.

Changesets

[6852] [6841] [6829] [6812] [6810] [6809] [6807] [6806] [6805] [6788] [6786] [6772] [6771] [6647] [6637] [6636] [6635] [6634] [6633] [6625] [6624] [6623] [6622] [6621] [6616] [6584] [6565] [6563] [6562] [6558] [6525] [6479]

After last change the branch was merged with trunk which was @ revision 6780.
It is possible that some things are lost during mere so be careful during reintegration.

Merged into the trunk in [6880].

Testing

^{(Place the testing results here.)}

Comments

^{(Write comments for this or later revisions here.)}