That would probably be extremely confusing. The managers initialize in the constructor and stop in the release method. But AbstractManager takes care of the release method by checking for the counter going down to zero and then calling releaseSub (yes - that is a horrible name). Managers actually override that method to perform whatever cleanup they need to do. My guess is that AbstractDatabaseManager's releaseSub method will call the disconnect method. So if anything is going to be renamed to stop it would be releaseSub. connect and disconnect sound right to me.
Ralph On Apr 27, 2013, at 12:58 PM, Gary Gregory wrote: > Should connect/disconnect just be start/stop? > > Gary > > On Apr 27, 2013, at 11:20, Nick Williams <nicho...@nicholaswilliams.net> > wrote: > >> >> On Apr 27, 2013, at 9:50 AM, Gary Gregory wrote: >> >>> On Sat, Apr 27, 2013 at 10:43 AM, Nick Williams >>> <nicho...@nicholaswilliams.net> wrote: >>> There already existed an o.a.l.log4j.core.appender.db package that was >>> empty. I discovered that I could create a base AbstractDatabaseAppender >>> that took care of some operations common to JDBC, JPA /and/ NoSQL >>> appenders. That led me to use the existing db package as follows: >>> >>> db/ >>> common DB appender classes >>> >>> What is in common? >>> >>> Gary >> >> - An AbstractDatabaseManager that defines connect and disconnect methods for >> concrete managers to implement, defines an isConnected method, defines a >> buffer size property, and controls buffering (which all types will support). >> >> - An AbstractDatabaseAppender that has a type parameter of LogEvent, >> requires an AbstractDatabaseManager implementation in its constructor, calls >> the manager's connect and disconnect methods when the appended is started >> and stopped (respectively), allows for manager replacement (configuration >> reloading) without event loss, and forwards events to the manager for >> writing to the database. >> >> This way, each database type will only need to implement >> connect/disconnect/write methods in the manager, implement an appender with >> a simple factory method to create the correct manager, and create whatever >> classes are necessary (if necessary) to support configuration. >> >>> >>> jdbc/ >>> JDBC appender classes >>> jpa/ >>> JPA appender classes >>> nosql/ >>> NoSQL appender classes >>> >>> I think that package structure makes a lot of sense. I'm open to convincing >>> arguments otherwise. >>> >>> Nick >>> >>> On Apr 27, 2013, at 9:37 AM, Gary Gregory wrote: >>> >>> > I think we should keep the packaging simpler: >>> > o.a.l.log4j.core.appender.jpa >>> > >>> > Gary >>> > >>> > On Apr 27, 2013, at 10:15, Nick Williams <nicho...@nicholaswilliams.net> >>> > wrote: >>> > >>> >> o.a.l.log4j.core.appender.db.jpa >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >>> > For additional commands, e-mail: log4j-dev-h...@logging.apache.org >>> > >>> >>> >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> Java Persistence with Hibernate, Second Edition >>> JUnit in Action, Second Edition >>> Spring Batch in Action >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>
