Using the CheckStyle ImportControl module, I was able to restrict uses of javax.persistence to o.a.l.l.core.appender.db.jpa, uses of org.mongodb to o.a.l.l.core.appender.db.nosql.mongo, etc. It doesn't "break the build" if someone violates this rule, which would be ideal. Currently it's just a nag on the CheckStyle report if someone violates this rule.
Other projects (Tomcat is the first that comes to mind) run CheckStyle pre-compile and fail if CheckStyle finds errors. Currently, there are too many other errors to do this in Log4j ... it would be weeks before it built again. However, at some point we could consider making this change to enforce the CheckStyle rules, after they have all been cleaned up. Nick On Apr 27, 2013, at 8:36 PM, Remko Popma wrote: > Nick, > > I think it is possible to restrict access from package A to package B in > Eclipse, > but this would be IDE-dependent. Not sure if that is good enough for you. > (I found this link, which may be outdated: > http://www.eclipsezone.com/eclipse/forums/t53736.html ) > > An alternative would be to use a naming convention like > > org.some.package.some.func > org.some.package.some.func.internal > > where the internal stuff should only be used in the func packages. > > > From: Nick Williams <nicho...@nicholaswilliams.net> > To: Log4J Developers List <log4j-dev@logging.apache.org> > Sent: Sunday, April 28, 2013 5:56 AM > Subject: Re: Restrict JPA classes to specific package? > > 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
