ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bram de Kruijff (JIRA)" <>
Subject [jira] [Commented] (ACE-316) Layout the OBR filesystem differently.
Date Fri, 12 Apr 2013 13:44:16 GMT


Bram de Kruijff commented on ACE-316:

A small analysis;

At present the client is 'in charge' of the filename as seen in BundleStore#put(String, InputStream)
and BundleStore#remove(String). This is reflected in the rest API (implemented by BundleServlet)
that supports POST /<filename> and DELETE /<filename>. This filename does not
actually have any meaning in the OBR context, but it is there.

If we want to keep this interface and only address the fs scalability we could simply have
to keep an internal mapping of filename to internal path or use a simple hashing strategy.
However, this is not very elegant and, as Marcel suggest with <BSN>/<version>,
we may want to use a more logical layout.

Therefore I suggest to break the API by removing the filename and use a file naming strategy
based on the actual bundle metadata. In addition, as the OSGi specification states that a
BSN should follow the reverse domain convention, I think it makes sense to create sub directories
for each part of the BSN using a split-by-dot.

Thus, the API would be BundleStore#put(InputStream) and BundleStore#remove(String), reflected
by the rest API supporting POST / (returning a 201 Created response with location) and DELETE
/<actual location>. The location for org.apache.commons.lang-2.6.jar would then be store/org/apache/commons/lang/2.6/org.apache.commons.lang-2.6.jar
> Layout the OBR filesystem differently.
> --------------------------------------
>                 Key: ACE-316
>                 URL:
>             Project: ACE
>          Issue Type: Question
>          Components: OBR
>            Reporter: Marcel Offermans
>            Assignee: Bram de Kruijff
> Currently, the OBR uses a single folder to store all artifacts. That does not scale too
well as OS specific directory limits might interfere. We should implement a more hierarchical
storage format, such as: <BSN>/<version> or even one where each part of the BSN
becomes a folder.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message