[
https://issues.apache.org/jira/browse/DERBY-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563597#action_12563597
]
Daniel John Debrunner commented on DERBY-3351:
----------------------------------------------
The monitor is an IoC container, but it's probably too specific to Derby to be
truly general purpose and probably more general purpose than Derby needs.
Modules.properties contains the list of modules that can be used by the system,
since it's the input to the monitor and the monitor can handle any module,
there is no requirement for the modules to be in the services.monitor package.
The monitor is code that manages the lifetime of modules in a Derby system.
Not sure what issue you are seeing with modules.properties being hard-coded,
it's the defined way that modules make themselves known to the system. There
can actually be multiple modules.properties, each with the same name but a
different location, typically as a resource in a jar file.
The mapping of format identifiers to instances may make more sense in the
services.io package. The only issue would be ensuring that when the monitor
(derby's system) is shutdown that any cached mapping of format identifier to
class is cleaned up. That's the only portion that is actually happening in the
monitor, and since the cache has the lifetime of the monitor it might make
sense to leave it there.
> Implement a Pluggable Storage Engine Architecture in Derby
> ----------------------------------------------------------
>
> Key: DERBY-3351
> URL: https://issues.apache.org/jira/browse/DERBY-3351
> Project: Derby
> Issue Type: New Feature
> Components: Services, SQL, Store
> Reporter: Dibyendu Majumdar
> Assignee: Dibyendu Majumdar
>
> My aim is to create a pluggable storage engine architecture for Derby, so
> that the default store implementation can be replaced with alternative
> storage engines. I have created my own storage engine which I would like to
> use with Derby's SQL layer, so that is a motivation. But I also think that
> this will benefit the community, and could lead to a pluggable storage engine
> architecture similar to that of MySQL.
> I am not yet sure where the storage engine boundary should lie. I would
> welcome input in this area.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
