You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Nick Williams <ni...@nicholaswilliams.net> on 2013/04/27 16:14:52 UTC
Restrict JPA classes to specific package?
Guys,
In order to make a JPA appender, as discussed we'll have to add an OPTIONAL dependency on the persistence API. I'd like to restrict the source code so that ONLY classes in o.a.l.log4j.core.appender.db.jpa can use the JPA classes. I know from working in Tomcat source code that you can, somehow, impose such a restriction. For example, Tomcat classes in o.a.t.websocket cannot import classes from o.a.t.websocket.server (it results in a pre-compile-time error, but classes in o.a.t.websocket.server CAN import classes from o.a.t.websocket.
In the context of Log4j 2 and Maven, how would I achieve the same to ONLY allow o.a.l.log4j.core.appender.db.jpa classes to import javax.persistence classes?
Nick
Re: Restrict JPA classes to specific package?
Posted by Remko Popma <re...@yahoo.com>.
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 <ni...@nicholaswilliams.net>
To: Log4J Developers List <lo...@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 <ni...@nicholaswilliams.net>
>To: Log4J Developers List <lo...@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 <ni...@nicholaswilliams.net>
>>To: Log4J Developers List <lo...@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 <ni...@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 <ni...@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 <ni...@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
>>>>>
>>>
>>
>>
>>
>
>
>
Re: Restrict JPA classes to specific package?
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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 <ni...@nicholaswilliams.net>
> To: Log4J Developers List <lo...@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 <ni...@nicholaswilliams.net>
>> To: Log4J Developers List <lo...@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 <ni...@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 <ni...@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 <ni...@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
>> >>>
>> >
>>
>>
>
>
>
Re: Restrict JPA classes to specific package?
Posted by Remko Popma <re...@yahoo.com>.
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 <ni...@nicholaswilliams.net>
To: Log4J Developers List <lo...@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 <ni...@nicholaswilliams.net>
>To: Log4J Developers List <lo...@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 <ni...@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 <ni...@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 <ni...@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
>>>>
>>
>
>
>
Re: Restrict JPA classes to specific package?
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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 <ni...@nicholaswilliams.net>
> To: Log4J Developers List <lo...@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 <ni...@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 <ni...@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 <ni...@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
> >>>
> >
>
>
Re: Restrict JPA classes to specific package?
Posted by Remko Popma <re...@yahoo.com>.
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 <ni...@nicholaswilliams.net>
To: Log4J Developers List <lo...@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 <ni...@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 <ni...@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 <ni...@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
>>>
>
Re: Restrict JPA classes to specific package?
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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 <ni...@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 <ni...@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 <ni...@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
>>>
>
Re: Restrict JPA classes to specific package?
Posted by Gary Gregory <ga...@gmail.com>.
Thank you for the explanation.
I've seen/used this naming pattern instead of fooSub:
- doFoo
- implFoo
- fooImpl
Gary
On Apr 27, 2013, at 16:17, Ralph Goers <ra...@dslextreme.com> 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 <ni...@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 <ni...@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<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Restrict JPA classes to specific package?
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ni...@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 <ni...@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 <ni...@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
>>
Re: Restrict JPA classes to specific package?
Posted by Gary Gregory <ga...@gmail.com>.
Should connect/disconnect just be start/stop?
Gary
On Apr 27, 2013, at 11:20, Nick Williams <ni...@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 <ni...@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<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Restrict JPA classes to specific package?
Posted by Ralph Goers <ra...@dslextreme.com>.
This all sounds reasonable to me. 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...?
Ralph
On Apr 27, 2013, at 8:20 AM, Nick Williams wrote:
>
> On Apr 27, 2013, at 9:50 AM, Gary Gregory wrote:
>
>> On Sat, Apr 27, 2013 at 10:43 AM, Nick Williams <ni...@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 <ni...@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
>
Re: Restrict JPA classes to specific package?
Posted by Nick Williams <ni...@nicholaswilliams.net>.
On Apr 27, 2013, at 9:50 AM, Gary Gregory wrote:
> On Sat, Apr 27, 2013 at 10:43 AM, Nick Williams <ni...@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 <ni...@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
Re: Restrict JPA classes to specific package?
Posted by Gary Gregory <ga...@gmail.com>.
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
> 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 <ni...@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<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Restrict JPA classes to specific package?
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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
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 <ni...@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
>
Re: Restrict JPA classes to specific package?
Posted by Gary Gregory <ga...@gmail.com>.
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 <ni...@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