Yes, I am using that expression to allow spaces in javadoc after a '*' locally and it works fine. Would love to commit if nobody objects.
About NewlineAtEndOfFile, I was wrong. The files I committed end in 0x0A (unix newline). Same with the files Ralph committed (and I think he works on a Mac). So perhaps we should add parameter lineSeparator="lf" to that rule and that will make the problem go away... ________________________________ From: Nick Williams <nicho...@nicholaswilliams.net> To: Log4J Developers List <log4j-dev@logging.apache.org> Sent: Monday, April 29, 2013 6:12 AM Subject: Re: Restrict JPA classes to specific package? As for the RegexpSingleline issue, this might help: http://stackoverflow.com/questions/9100059/checkstyle-trailing-spaces-regexp-issue As for the NewlineAtEndOfFile issue, I would suggest that files should NEVER be committed to SVN with CRLF endings. This is an incorrect ending. This is one place Git got it right: CRLF is prohibited everywhere, and Git for Windows automatically converts on commit. My suggestion here: - Find all files in the project with CRLF endings and convert them. - Add a pre-commit check in SVN that prohibits the commit if any files have CRLF in them. My $0.02. Nick On Apr 28, 2013, at 4:00 PM, Remko Popma wrote: About CheckStyle: >I would like to change the "RegexpSingleline" rule to allow spaces in javadoc >after a '*'. > > >Also, the NewlineAtEndOfFile check seems broken. >(http://checkstyle.sf.net/config_misc.html#NewlineAtEndOfFile) >If I commit something on a PC the file will end with "crlf". >Then someone on a Mac builds the site with mvn site, that file will be marked >as an error (even though it ends in a newline). >The NewlineAtEndOfFile seems to only allow one kind of new line, which you can >hard-code or make system dependent. >But it won't allow all newlines... System dependent only works if all devs use >the same system. >(Sorry for ranting... :-) Bed time for me.) > > > >________________________________ > From: Nick Williams <nicho...@nicholaswilliams.net> >To: Log4J Developers List <log4j-dev@logging.apache.org> >Sent: Monday, April 29, 2013 5:48 AM >Subject: Re: Restrict JPA classes to specific package? > > > >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 >>>>> >>> >> >> >> > > >
