Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Concurrent, persistent background process for a J2EE container

Reply
Thread Tools

Concurrent, persistent background process for a J2EE container

 
 
Arne Vajhj
Guest
Posts: n/a
 
      08-29-2008
Ignatius Space wrote:
> Writing logs to a database... why? The logs should be simple, so that
> they are present even when things don't work. How are you going to
> debug database problems when the logs didn't get written because the
> database was supposed to be hold the logs in the first place? This
> seems circular, and unnecessarily complex. Even baroque.
>
> If I got an app that wrote logs to a database, I think I'd curse your
> name. Just saying....


It is a goofiest use of logs if you need an audit trail.

I fatten with your comments for unacceptable troubleshooting log.

Arne



- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Ibrahim Nafie Al-Ahram, Egypt, November 5

"Is it anti-semitism ? Or is it a question of recognising
expansionist and aggressive policies?

Israel's oft-stated weapon of anti-semitism has become truly
exposed ...

Tel Aviv has been called upon to explore the reasons behind
the Middle East conflagration. It is these reasons that make
Israel a rogue state in the real sense of the word.
Enough of crying 'anti-semitism' to intimidate others."

 
Reply With Quote
 
 
 
 
Donkey Hottie
Guest
Posts: n/a
 
      08-29-2008


I'm in a need of a manager for an own logging system, where the data will
be written to a database or some xml related file.

I would like to dedicate a process or a thread for writing the log, and in
addition to that for some cleanup and other management.

I'm not allowed to use JMS.

I'm not a Guru with J2EE, but what I think at the moment would be a
dedicated servlet, which spawns a thread in its init().

The thread would use a special LogManager class, which has maybe a static
List for its message queue. That would be "written" and "read" in
synchronised methods.

Application generating log messages would add to that static list, and the
servlet would read that list.

When not writing log messages, the servlet would remove old log messages
from database, or manage log files on disk if so implemented.

I'm I on a decent track?

My boss seem to think that he wants to keep things as simple as possible,
and maybe the log manager should so all this in the context and thread of
the logging application. That might be well possible, because out app run
on intranets, and there will not be much traffic.

But I just fancy that the messages should be put on a queue, and managed by
a singleton.

 
Reply With Quote
 
 
 
 
Mark Space
Guest
Posts: n/a
 
      08-29-2008
Donkey Hottie wrote:

> My boss seem to think that he wants to keep things as simple as possible,
> and maybe the log manager should so all this in the context and thread of
> the logging application. That might be well possible, because out app run
> on intranets, and there will not be much traffic.


I think your boss is correct. The Java LogManager is pretty robust.
I'd definitely try that first, and only abandon it when it was proven it
couldn't work. The LogManager is pretty sophisticated, it'll even
rotate your logs for you.

Writing logs to a database... why? The logs should be simple, so that
they are present even when things don't work. How are you going to
debug database problems when the logs didn't get written because the
database was supposed to be hold the logs in the first place? This
seems circular, and unnecessarily complex. Even baroque.

If I got an app that wrote logs to a database, I think I'd curse your
name. Just saying....
 
Reply With Quote
 
Donkey Hottie
Guest
Posts: n/a
 
      08-29-2008
Mark Space <(E-Mail Removed)> wrote in
news:g99bm8$ng5$(E-Mail Removed):

> Donkey Hottie wrote:
>
>> My boss seem to think that he wants to keep things as simple as
>> possible, and maybe the log manager should so all this in the context
>> and thread of the logging application. That might be well possible,
>> because out app run on intranets, and there will not be much traffic.

>
> I think your boss is correct. The Java LogManager is pretty robust.
> I'd definitely try that first, and only abandon it when it was proven
> it couldn't work. The LogManager is pretty sophisticated, it'll even
> rotate your logs for you.
>
> Writing logs to a database... why? The logs should be simple, so that
> they are present even when things don't work. How are you going to
> debug database problems when the logs didn't get written because the
> database was supposed to be hold the logs in the first place? This
> seems circular, and unnecessarily complex. Even baroque.
>
> If I got an app that wrote logs to a database, I think I'd curse your
> name. Just saying....
>


We can't use java.util.logging for this. Boss wants "structured" data, not
flat text files.

Actually our logging needs are 3 fold.

We have a web type server managing identities and access, kind of an
Identity and Access management solution. It's requests and actions must be
logged, and plain text web server type log file is not enough.

Then we have and Administration GUI Web Service for it, and every action
there must be logged, identifying actions, entity and it's attributes, when
updates, old and new values logged. Very "structural" data.

Finally we have "normal" debug log, which can be handled with
java.util.logging (currently we use Log4j, but boss wants to get rid of
open source).

Our admin/access audit logs will be written to (implementation may vary) to
a database or disk file in some structured format, and those logs will be
available in the Management Console GUI. Debug logs must not be visible in
the GUI, but they must be turned on and off from said GUI. I'm prepared to
let log4j go and use java.util.logging for that, it works ok.

 
Reply With Quote
 
Donkey Hottie
Guest
Posts: n/a
 
      08-29-2008
Mark Space <(E-Mail Removed)> wrote in
news:g99bm8$ng5$(E-Mail Removed):

>
> If I got an app that wrote logs to a database, I think I'd curse your
> name. Just saying....
>



Yes. Different kinds of logs. Error and debug to normal logger file, but
Audit data to database, and accessible to the end users via browser.



 
Reply With Quote
 
Michael Justin
Guest
Posts: n/a
 
      08-29-2008
Donkey Hottie wrote:

> Finally we have "normal" debug log, which can be handled with
> java.util.logging (currently we use Log4j, but boss wants to get rid of
> open source).



From Wikipedia:

"Sun's goal is to replace the parts that remain proprietary and
closed-source with alternative implementations and make the class
library completely free and open source."

http://en.wikipedia.org/wiki/Java_(s...#Free_software



So boss wants to get rid of Java altogether soon?

SCNR
--
Michael Justin
SCJP, SCJA
betasoft - Software for Delphi™ and for the Java™ platform
http://www.mikejustin.com - http://www.betabeans.de
 
Reply With Quote
 
Donkey Hottie
Guest
Posts: n/a
 
      08-29-2008
Michael Justin <(E-Mail Removed)> wrote in news:48b83d15$0
$22212$(E-Mail Removed):

> Donkey Hottie wrote:
>
>> Finally we have "normal" debug log, which can be handled with
>> java.util.logging (currently we use Log4j, but boss wants to get rid of
>> open source).

>
>
> From Wikipedia:
>
> "Sun's goal is to replace the parts that remain proprietary and
> closed-source with alternative implementations and make the class
> library completely free and open source."
>
> http://en.wikipedia.org/wiki/Java_(s...#Free_software
>
>
>
> So boss wants to get rid of Java altogether soon?
>
> SCNR


That's what I told him too ;D

 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      08-29-2008
Michael Justin wrote:
> Donkey Hottie wrote:
>> Finally we have "normal" debug log, which can be handled with
>> java.util.logging (currently we use Log4j, but boss wants to get rid
>> of open source).

>
> From Wikipedia:
>
> "Sun's goal is to replace the parts that remain proprietary and
> closed-source with alternative implementations and make the class
> library completely free and open source."
>
> http://en.wikipedia.org/wiki/Java_(s...#Free_software
>
> So boss wants to get rid of Java altogether soon?


Get rid of SUN Java maybe. Java != SUN Java.

Arne

 
Reply With Quote
 
Arne Vajhj
Guest
Posts: n/a
 
      08-29-2008
Donkey Hottie wrote:
> We can't use java.util.logging for this. Boss wants "structured" data, not
> flat text files.


Even java.util.logging support custom formatters and handlers.

(Log4j is better though)

> Our admin/access audit logs will be written to (implementation may vary) to
> a database or disk file in some structured format, and those logs will be
> available in the Management Console GUI.


java.util.logging and Log4j can be customized for a task like that.

Arne
 
Reply With Quote
 
Arne Vajhj
Guest
Posts: n/a
 
      08-29-2008
Donkey Hottie wrote:
> but boss wants to get rid of
> open source).


Does he also want to avoid files with multiple of 13 number
of lines because 13 is an unlucky number ?

Because that is about as serious.

If an open source product solves the business and problem
and the license is compatible with your usage, then there
are really no reason to avoid it.

Arne
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Persistent field and Persistent properties - difference gk Java 7 10-12-2010 09:43 PM
Perl process as a unix background process gbostock@excite.com Perl Misc 14 08-15-2009 02:41 PM
C container and persistent library ? llothar C Programming 45 03-06-2007 01:33 AM
STL: container's values setup by another container Maitre Bart C++ 2 02-11-2004 12:11 AM
std::container::iterator vs std::container::pointer Vivi Orunitia C++ 11 02-04-2004 08:09 AM



Advertisments