Thank you!
On 06/11/2013 10:46 AM, Ceki Gülcü wrote:
On 6/6/2013 2:22 AM, Steve Cohen wrote:
On 06/05/2013 07:06 PM, Steve Cohen wrote:
Documentation suggestion:
not using the attribute should be strongly recommended for use on
the Windows platform, especially if the program is one that will
On 6/6/2013 2:22 AM, Steve Cohen wrote:
On 06/05/2013 07:06 PM, Steve Cohen wrote:
Documentation suggestion:
not using the attribute should be strongly recommended for use on
the Windows platform, especially if the program is one that will be run
by more than one user.
It is not just a ques
On 06/05/2013 07:06 PM, Steve Cohen wrote:
Documentation suggestion:
not using the attribute should be strongly recommended for use on
the Windows platform, especially if the program is one that will be run
by more than one user.
It is not just a question of more than one process holding the f
On 06/05/2013 05:52 PM, Steve Cohen wrote:
Although I can't quite see from the source how this suggestion works.
But I will try it (tomorrow - it's been a long day).
A closer look at source revealed how it works.
And it works. I couldn't let it go and tried it.
Documentation suggestion:
not
On 06/05/2013 05:44 PM, Steve Cohen wrote:
I think I've found my answer. It's at
http://logback.qos.ch/codes.html#renamingError
Although I can't quite see from the source how this suggestion works.
But I will try it (tomorrow - it's been a long day).
_
On 06/05/2013 05:32 PM, Steve Cohen wrote:
I did see the the "rename error" message from logback in the console
window in the environment I do have access to.
It seems that the main logfile needs to have permissions of full rights
for all users if multiple users are going to run the program, in
On 06/05/2013 04:46 PM, Steve Cohen wrote:
On 06/05/2013 03:21 PM, ceki wrote:
On 05.06.2013 22:15, Steve Cohen wrote:
1) this is Swing app running under javaw so there is no console. and
it's not a web app so no easy way to hook up the servlet.
2) Corporate security prevents me from having
On 06/05/2013 03:21 PM, ceki wrote:
On 05.06.2013 22:15, Steve Cohen wrote:
1) this is Swing app running under javaw so there is no console. and
it's not a web app so no easy way to hook up the servlet.
2) Corporate security prevents me from having access to production
machines and I have a l
On 05.06.2013 22:15, Steve Cohen wrote:
1) this is Swing app running under javaw so there is no console. and
it's not a web app so no easy way to hook up the servlet.
2) Corporate security prevents me from having access to production
machines and I have a low degree of confidence that the envi
On 06/05/2013 02:46 PM, ceki wrote:
Hi Steve,
The internal status messages are often very helpful in such
circumstances. Did you set the debug attribute of the
element set to true?
see also [1] and [2]
[1] http://logback.qos.ch/manual/configuration.html#automaticStatusPrinting
[2] http://lo
Hi Steve,
The internal status messages are often very helpful in such
circumstances. Did you set the debug attribute of the
element set to true?
see also [1] and [2]
[1] http://logback.qos.ch/manual/configuration.html#automaticStatusPrinting
[2] http://logback.qos.ch/manual/configuration.
How does one debug windows permissions - just to even see what they are?
I tried cacls and I see all these terms like
FILE_READ_ATTRIUTES, FILE_WRITE_EA, etc. which as far as I can tell are
not defined ANYWHERE I can find on the web.
Does anyone know what Windows 7 permission(s) would be necess
Yes that could be it. But note that in the comments of LOGBACK-204 someone
notes that clean at startup is not the same as roll at startup. But anyhow it
might be enough for you.
David
On 5 Jun 2013, at 19:51, Steve Cohen wrote:
> I may be wrong but it looks like this could be the solution to
I may be wrong but it looks like this could be the solution to our problem:
http://jira.qos.ch/browse/LOGBACK-92
If I just turn this property on, it could give me what I need.
Or am I misunderstanding something?
On 06/05/2013 01:35 PM, David Roussel wrote:
On 5 Jun 2013, at 19:32, Steve Cohe
On 5 Jun 2013, at 19:32, Steve Cohen wrote:
>> Have you looked at the changes since 1.0.7 to see if any apply?
> Is there a place where these are listed?
http://logback.qos.ch/news.html___
Logback-user mailing list
Logback-user@qos.ch
http://mailman.qo
It's not definitive but there is an open bug for roll on startup.
http://jira.qos.ch/browse/LOGBACK-204
Only thing definitive is the source code.
David
On 5 Jun 2013, at 19:26, Steve Cohen wrote:
> Hmm, I have rolled my own roll-on-startup policy but that is not, as written
> compatible wit
On 06/05/2013 12:59 PM, David Roussel wrote:
Have you looked at the changes since 1.0.7 to see if any apply?
Is there a place where these are listed or do I have to roll my own JIRA
query?
___
Logback-user mailing list
Logback-user@qos.ch
http://mai
Hmm, I have rolled my own roll-on-startup policy but that is not, as
written compatible with a roll-by-day setup, as it uses different file
naming conventions. I use it for personal debugging but not in
production. I'm not sure it's possible to combine the two in a single
policy, if in fact,
Have you looked at the changes since 1.0.7 to see if any apply?
Lack of rolling is curtly a difficult one to debug. Best way is to configure
one roll per minute or more often and do a soak test.
Roll at startup is discussed here.
http://stackoverflow.com/questions/2492022/how-to-roll-the-log-f
On 06/05/2013 12:35 PM, Robert Kuhar wrote:
Also, if your app isn't running when the trigger is me, it is my
understanding and observation that the logs won't roll.
"When the trigger is me"? What does this mean? I had thought that the
rollover would happen whenever the day (in my case) cross
Every time this has happened to me the root cause has been a permissions
problem. Do you have a means to tailing standard out/err to see if the
tell tale "permissions" problem is showing up there?
Also, if your app isn't running when the trigger is me, it is my
understanding and observation that
21 matches
Mail list logo
