logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <rem...@yahoo.com>
Subject Re: Restrict JPA classes to specific package?
Date Sun, 28 Apr 2013 21:00:24 GMT
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 <nicholas@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 <nicholas@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 <nicholas@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 <nicholas@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 <nicholas@nicholaswilliams.net>
wrote:
>>>>> >
>>>>> >> o.a.l.log4j.core.appender.db.jpa
>>>>> >
>>>>> > ---------------------------------------------------------------------
>>>>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>> >
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> E-Mail: garydgregory@gmail.com | ggregory@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
>>>> 
>> 
>
>
>
Mime
View raw message