db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cheng Che Chen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-927) Cleanup code in the monitor to clarify the relationship between StorageFactory and PersistentService
Date Fri, 12 Oct 2007 09:50:50 GMT

    [ https://issues.apache.org/jira/browse/DERBY-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534258
] 

Cheng Che Chen commented on DERBY-927:
--------------------------------------

Folks, I have a question that is related to this area.  I was examining the code in StorageFactoryService.removeServiceRoot()
and saw an assert-statement expecting (serviceName) and storageFactory.getCanonicalName()
to be equal.

It is not clear to me why the two strings must be equal.  The (storageFactory) variable comes
from StorageFactoryService.privGetStorageFactoryInstance().  Inside that function, the (subSubProtocol)
portion of the (serviceName/databaseName) is chopped off before the (storageFactory) is initialized
with the parameters.

So if (serviceName) contains a subSubProtocol prefix, then it is possible for the assert-statement
to fail, no?


> Cleanup code in the monitor to clarify the relationship between StorageFactory and PersistentService
> ----------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-927
>                 URL: https://issues.apache.org/jira/browse/DERBY-927
>             Project: Derby
>          Issue Type: Improvement
>          Components: Services
>            Reporter: Daniel John Debrunner
>            Assignee: Daniel John Debrunner
>            Priority: Minor
>
> The addition of the StorageFactory code into the BaseMonitor code muddied the water with
respect to what is a service and what is a storage factory.
> Cleanup the code and add comments and/or a package.html to describe what is going on.
> Look at loading the storage factories through the modules.properties rather than the
hard-coded list and thus gain the benefit of the standard module environment
> checking (jvm level and dependent classes) and ensure classes are loaded from modules.properties
consistently.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message