On Fri, Nov 12, 2010 at 5:56 PM, Alex Milowski <alex@...> wrote:
> On Fri, Nov 12, 2010 at 2:58 AM, Dmitriy Shabanov <shabanovd@...>
> > On Thu, Nov 11, 2010 at 10:58 PM, Alex Milowski <alex@...>
> >> By changing the URI slightly to include the pool instance name, the
> >> test will succeed:
> >> conf =
> >> This fixes my problem.
> > That is workaround, not a fix. Take o look at /db/system/security, all
> > should not handle information about exist instance, as I did say, full
> > (the instance have at begin of uri, not in the path part) will solve your
> > problem. (I'll have time to do it on weekend only)
> Whether you put it at the beginning or end, this is still a cache. If
> the "key" is unique for each BrokerPool instance, this should work OK.
> I question the design of this API. I don't understand why we've
> inserted Configurator.parse() in a few places when it seems we should
> just have reference to a configuration object that understands when it
> might be stale.
It do parse configuration each time it change, searching for the
> For example, in SecurityManagerImpl.attach() we have a direct
> reference to the BrokerPool to which it is being attached. We can get
> the configuration information directly from that. If we need then
> instantiate another configuration that may be loaded from parsing
> documents internal to the database, it seems like that object should
> be associated with the BrokerPool before it is passed to the
> SecurityManager via attach(). That way it can just get a reference to
> the object whose implementation might be backed by objects in the
> database or might come from somewhere else (e.g. a custom object).
As I did say, it's possible, but require some work ... I did interpret
wrongly several facts: getInstance bug & some discussions.
> I don't store my configuration information in the database. Any
> change that requires this is moving in the wrong direction for my
That is not conf.xml file, that is more like transformation xml -> java
object -> xml