incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <>
Subject Re: OIDs for services
Date Thu, 31 May 2012 06:41:47 GMT
Hi Rob,
That was me, obviously, from the OID refactoring.  I guess we were missing
a test that didn't catch this required behaviour.

I do, vaguely, remember this support for
"repository#org.package.ClassName", but I've never used it myself.  If we
want to reinstitute it, then we need to consider what the OID for such an
object would be.  In particular, note that the string version of that OID
cannot contain  a "#" symbol, because we want these things to appear in

I agree that the interface in ObjectStorePersistence is going to need to
change to support this.

I think we can resolve this relatively easily though... we could reserve
the @ObjectType("repository")
for, and we
could change the logic to short-circuit the OidGenerator and notice
services of this specific type and then use the getId() (using the
ServiceUtil utility class) as the OID's identifier:

public class SimpleRepository { ... }

In other words, two entries in of:,repository#com.mycompany.Order

would correspond to services with OIDs "repository:com.mycompany.Customer"
and "repository:com.mycompany.Order" respectively.

For regular (hand-crafted) repositories such as CustomerRepository, the OID
can be manufactured as per normal.

In terms of the ObjectStorePersistence API that needs to change, it would
seem that the only actual uses are in
PersistenceSession#createServiceAdapters() and
PersistenceSession#getService(Object).  In both cases we are dealing with a
pojo that we know is an instance of a service, either an instance of
SimpleRepository instantiated for a particular class, or a regular
hand-crafted repository, eg CustomerRepository.  If we change the
ObjectStorePersistence API to be simply getOidForService(Object
servicePojo), then I think there ought to be enough info to figure things
out at that stage

For example, something like:

private final static ObjectSpecId SIMPLE_REPO_SPEC_ID
= ObjectSpecId.of("repository");

public RootOid getOidForService(Object servicePojo) {
    final ObjectSpecification serviceSpecification =
    if(serviceSpecification.getSpecId().equals(SIMPLE_REPO_SPEC_ID) {  //
special case handing
        String identifier =;
        return RootOid.create(SIMPLE_REPO_SPEC_ID, identifier);
    // ... remaining processing as is ...

within PersistenceSession, the current Map<ObjectSpecId, RootOid>
servicesByObjectType map would need to change to be Map<String, RootOid>.

Something like that, anyway.

Rob... when you raise that ticket, could you copy the above commentary into
it as a starting point for whoever picks it up (probably me or you).


On 31 May 2012 00:16, Robert Matthews <> wrote:

> I've just noticed that OIDs for services have been broken, such that
> multiple simple repositories (declared using repository#org.package.**ClassName
> in the services list) and the option to replace one service implementation
> with another will not work.
> Services were designed to be identified by an Id (using the getId() method
> in a service class) so that services were install afresh during each start
> up and not persisted, and both these uses could be accommodated.  The code
> has be changed to use a specification instead of the id (specifically, but
> not limited to the ObjectStorePersistence interface).  Was this simply an
> oversight in trying to move away from a simple string to a relevant type or
> was something trying to be achieved here that I am not aware of?
> I will raise a ticket for this and restore the original functionality, but
> first I want to make sure there is nothing else that I need to consider.
> Regards
> Rob

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message