Yes, you should include whatever is needed to make them unique. In addition, if they contain something like a timeout value that you want to be dynamically updatable then that needs to be included too.
Sent from my iPad On Apr 29, 2013, at 6:35 AM, Nicholas Williams <[email protected]> wrote: > *so I should include the connection information in my > _DatabaseManagers' names... > > Sent from my iPhone, so please forgive brief replies and frequent typos > > On Apr 29, 2013, at 8:34, Nicholas Williams > <[email protected]> wrote: > >> Oh! That makes sense! So I should include the connection information >> in my FileManager's name so that a new one gets created if the >> connection information changes. Right? >> >> Nick >> >> Sent from my iPhone, so please forgive brief replies and frequent typos >> >> On Apr 29, 2013, at 8:30, Ralph Goers <[email protected]> wrote: >> >>> The FileManager includes the file name in its name. Likewise the >>> SocketManager would include the host & port. So if the file name is >>> changed the manager will be stopped. >>> >>> Sent from my iPad >>> >>> On Apr 28, 2013, at 10:53 PM, Nick Williams <[email protected]> >>> wrote: >>> >>>> Okay. So consider this scenario: Someone has the FileAppender configured >>>> to write to file X. They change the configuration to write to file Y. >>>> Since the FileManager already exists writing to file X, the FileManager >>>> won't be stopped. Its use count will increase to 2 and the >>>> newly-configured FileAppender will use it as well. The old FileAppender >>>> will stop and the FileManager's use count will decrease back to 1, but >>>> it's being used by the new FileAppender. The newly configured FileAppender >>>> is still writing to file X, even though the configuration says File Y, >>>> because the FileManager hasn't been reloaded. >>>> >>>> Do I understand that incorrectly? Am I missing something? >>>> >>>> Nick >>>> >>>> On Apr 29, 2013, at 12:47 AM, Ralph Goers wrote: >>>> >>>>> When a reconfiguration takes place a new configuration is first created. >>>>> All the Filters, Appenders, etc named in the configuration will be >>>>> created. However, when the Appender calls getManager() it may find that >>>>> one already exists with the name it is searching for. If so, that >>>>> manager's use count will be incremented and the new Appender will >>>>> reference it. Then the old configuration is stopped. During this time >>>>> Appenders will call the release method on the manager and the manager's >>>>> use count will be decremented. A manager doesn't actually stop until its >>>>> use count is decremented to 0. This means database connections, sockets, >>>>> streams, etc will all continue on into the new Appenders. If the new >>>>> configuration no longer has a particular appender then the use count on >>>>> that manager will decrement to zero and it will be stopped. >>>>> >>>>> Ralph >>>>> >>>>> On Apr 28, 2013, at 9:52 PM, Nick Williams wrote: >>>>> >>>>>> Guys, >>>>>> >>>>>> I'm almost ready to submit a patch for JDBC/JPA/MongoDB/CouchDB, but I'd >>>>>> like a little bit of instruction on something. I want to make sure I'm >>>>>> understanding things correctly, because I'm getting ... strange ... >>>>>> results when reloading configuration in between unit tests. >>>>>> >>>>>> So, if you have an Appender that has a Manager, and than appender has >>>>>> written events, and LoggerContext.reconfigure() is called, what is done >>>>>> with the existing Appender and Manager instances? Basically, can someone >>>>>> explain this whole lifecycle? I want to make sure I'm using this pattern >>>>>> right. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Nick >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >> <smime.p7s> > <smime.p7s> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
