Ralph nailed it. Also to an earlier point/question Ralph raised that isn't included below:
> However, note that we have o.a.l.log4j.net which has all the networking > related managers. Perhaps it should have been under appenders as well, but it > also supports servers as well as managers, which probably isn't as likely > with db appenders...? The SocketAppender, SmtpAppender, JMSQueueAppender, and JMSTopicAppender are all in o.a.l.log4j.appender. o.a.l.log4j.net appears to mostly be servers and receivers and a few managers. I think the db package is in the right place. I would actually argue that some of the net package classes actually belong in the appender package. But I digress... Back to the original question :-) how would I achieve restricting access to javax.persistence so that other parts of the Core aren't polluted with JPA classes? I know it's possible (re: Tomcat), I just don't know how to do it in Log4j. Nick On Apr 27, 2013, at 3:17 PM, Ralph Goers wrote: > 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 >>> >
smime.p7s
Description: S/MIME cryptographic signature
