{5} Assigned, Active Tickets by Owner (Full Description) (27 matches)

In order to more quickly provide features and bug fixes to users, the entire installation and deployment workflow should be significantly simplied. Ideally, the server would automatically detect changes to its own components or to the clients, download the changes, and silently upgrade. New client versions would be downloaded to the client machines on the next launch. In other cases, a one-click installer/upgrader would also be useful.

Various issues

Start up checks

Currently there are several situations and warnings which are only printed after start up. These could be performed during "bin/omero admin start" or install:

• check for omero.data.dir (/OMERO)
• check dbpatch level
• check Java version
• on failure, run "bin/omero server stop"
• on failure, print common things to look into

This might should be just large warnings or possibly errors to prevent startup.

See: #1037 (bin/omero db install)

Currently FS returns OmeroFSError for all exceptions. A richer hierarchy of exceptions is necessary for clients to provide adequate feedback to users.

Hey guys.

I'm just working down in the belly of search and was wondering if the plan was to make access to an OMERO.fs file via the OriginalFileService. That's currently what I'm injecting.

It's obviously ok if that has to change, but in the way of another use case I currently do this:

    protected Iterable<Reader> parse(OriginalFile file) {
        if (files != null && parsers != null) {
            if (file != null && file.getFormat() != null) {
                String path = files.getFilesPath(file.getId());
                String format = file.getFormat().getValue();
                FileParser parser = parsers.get(format);
                if (parser != null) {
                    return parser.parse(new File(path));
                } else {
                    parser = parsers.get("*");
                    if (parser != null) {
                        return parser.parse(new File(path));
                    }
                }
            }
        }
        return FileParser.EMPTY;
    }

where "files" is the OriginalFileService. I can teach parser.parse() to read from pretty much anything that implements the java.io.Reader interface.

org.openmicroscopy.shoola.env.rnd.RenderingServiceException: An error occurred while trying to set the codomain interval. 
omero.InternalException 
serverStackTrace = "ome.conditions.InternalException:  Wrapped Exception: (java.lang.IllegalStateException): 
Object unloaded:ome.model.enums.Family:Id_1 
 at ome.model.enums.Family.errorIfUnloaded(Family.java:315) 
at ome.model.enums.Family.getValue(Family.java:136) 
at omeis.providers.re.quantum.QuantumStrategy.defineMapper(QuantumStrategy.java:104) 
at omeis.providers.re.quantum.QuantumStrategy.setMapping(QuantumStrategy.java:300) 
at omeis.providers.re.QuantumManager.initStrategies(QuantumManager.java:104) 
at omeis.providers.re.Renderer.updateQuantumManager(Renderer.java:402) 
at omeis.providers.re.Renderer.setCodomainInterval(Renderer.java:740) 
	 

The current RepositoryInfo service implementation has a few issues:

• file system sizes are not being calculated properly; therefore the sanity checking is being disabled for 4.0
• the RepositoryTask class will eventually become a performance problem since it does not keep track of what has already been deleted (like PersistentEventLogLoader) and simply queries for all deletes

Some (or all) of these tasks may be more appropriately passed off to OmeroFs.

The paradigm of the existing return values for methods located in IRenderingSettings is that certain settings applications could fail or succeed. As such, we have methods such as:

Map applySettingsToDataset(@NotNull long from, @NotNull long to);

where the <k,v> pairs are {true, List<Long>} and {false, List<Long>} signifying the above failure and success conditions. The methods in the service which reset rendering settings do not follow the paradigm because reseting of rendering settings should never fail. Failure conditions during methods which reset rendering settings are handled by throwing exceptions; in this case the entire transaction fails.

This said, it would be convenient for application developers to be able to know exactly which images have had their rendering settings reset when calling methods which take a Dataset, Category, etc.

sha1 not created for the projected image. "pending" in DB

It was found in r582 that calls to session.merge() were cascading to all instances so that versions in Experimenter, EventTypes, etc. are being incremented. This was hellish for clients trying to deal with optimistic locks.

This is a hibernate bug. See  http://opensource.atlassian.com/projects/hibernate/browse/HHH-1401 (version 3.2 may help)

Revisions r590, r591, and r597 made temporary fixes so work could continue without versions.

Before we close this, we need to re-instate versions and finish the update tests (like DetachedPixelsGraphTest) which test the possible combinations of transient/detached graphs.

• Transient root with:
  • transient entity
  • "transient" collection
  • unloaded entity
  • filtered collection (ERROR)

• Detached root with:
  • transient entities/collections
  • detached entities/collections
  • filtered entities/collections

Also we need to make sure that the bug fix really worked, i.e.:

• re-merging unchanged detached --> no version increment
• re-merging changed --> version++ (also re: collections)

A possible Abstract test would be of the form:

  class {
    createGraph();
    saveGraph();
    checkIds();
    checkVersions();
    checkLogs();
  }

Originally  http://bugs.openmicroscopy.org.uk/show_bug.cgi?id=646

With the EventMethodInterceptor (r788) it would be easy to raise Spring events (or even JMS messages) if we ever were to start using them internally.

For #182, it is important to set Permissions to null by default. However, Hibernate has some quirks when an interceptor un-nulls a null-valued component. See  HHH-2027 for more. Until this is fixed, we'll workaround.

While implementing #2025, several further improvements/refactorings were left undone:

• Remove "omero.ldap.protocol"; this can be detected from the URL (DONE)
• Improve support for two bases (one user, one group) (ON USER REQ)
• Add support for group owners / group permissions (part of #2029?)
• Refactor IAdmin.reportForgottenPassword now that PasswordProvider handles setting

APIs to possibly make use of:

•  http://forum.springsource.org/showthread.php?55955-Persistent-search-with-spring-ldap
•  http://forum.springsource.org/showthread.php?41918-How-to-get-dn-of-elements-after-a-search

This ticket subsumes:

• #437 - Remove local.properties.default
• #556 - Ability to store omero.data.dir in local.properties rather than omero.properties
• #660 - Copying local.properties into the ear file
• #681 - Add db.port and data.dir to setup script
• #718 - Preferences based configuration
• #734 - Location for LDAP read/write values
• #741 - proper defaults
• #746 - sensible javac|javadoc.maxmem values
• #753 - central administration
• #754 - A writable configuration store for ldap

And will also include the merging of ice.config & glacier2.config with omero.properties (with overrides in local.properties).

Other possibilities:

• Allow comma separated values in OMERO_CONFIG for prefs.class
• Allow a path value in OMERO_CONFIG for prefs.class
• Failover to using $HOME/.omero.config when Java not present from Python
• Warn when Java preferences or .omero.config are not umask 077
• Use IConfig as the central configurator which is injected into beans. This would allow hot-swapping properties
• Outline all environment properties which are of importance for OmeroBuild, OmeroBlitz, OmeroGrid, etc. (ICE_CONFIG in grid?, OMERO_CONFIG, OMERO_MASTER, OMERO_NODE, ..., NOMAKE, ...)

As mentioned in Pragmatic Project Automation, a self-test ant target of the form:

  java omero self-test

or

  bin/omero self-test

which checks Java version, file/directory sanity (existence, permissions, etc.), database availablility, and other requirements for a production system. See <check-system/> for a first draft.

OA-viewer can display segger results already. Just need to attach them to Image, make them available to OAV and add javascript command to load them (similar to pdb files).