Monitoring/Alerting on production.log

Is there a way to monitor the production logfile so that
when an error
occurs, it can trap and email the error to me?
Alternatively, is it
possible to write errors out to a separate logfile.

A few months ago I read something where a couple of guys
where doing
this on their production site. Their goal was to get errors
down to
practically zero in a short period of time.

I know its possible to hack the logging to get something
like this in
place, just wanted to know if someone already had a solution
before I
started re-inventing the wheel.

Regards
- Ericson Smith


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Deploying Rails" group.
To post to this group, send email to
rubyonrails-deploymentgooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-deployment-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-deployment
?hl=en
-~----------~----~----~----~------~----~------~--~---

The class org.jbpm.graph.def.ProcessDefinition describes
jPDL processes. Some of its properties are useful for BPEL
processes as well. Some of these properties are *not* useful
for BPEL and merely bloat ProcessDefinition instances that
describe BPEL processes. Further, BPEL processes require
some additional properties not defined by
ProcessDefinition.

Unlike Node, ProcessDefinition does not have subclasses in
the jPDL model and does not define a discriminator. This
prevents inheritance using the table per class hierarchy
strategy. There are at least two ways to work around that
limitation:

1. Use table-per-subclass (i.e. an additional
BPEL_PROCESSDEFINITION table)
2. Override the default ProcessDefinition mapping with an
alternate mapping that contains the same properties and adds
a discriminator

So far (2) has been the option of choice, as a few extra
fields in the JBPM_PROCESSDEFINITION table do not seem to
justify the table join overhead imposed by (1). However, (2)
has a big drawback: the alternate mapping can get out of
sync with the default mapping. 

I'm looking for a way to avoid overriding the default
ProcessDefinition mapping. The options, in increasing order
of complexity, are:

0. Do nothing. Keep synchronizing.

1. Switch to table-per-subclass.

2. Add the discriminator to the ProcessDefinition mapping,
even if unused in jBPM jPDL.

3. "Pull up" the fields from BpelDefinition to
ProcessDefinition. 

->In this regard, jPDL has an edge over BPEL because it
can add properties to the core graph objects even if they
don't make sense for BPEL. Since the BPEL subproject resides
in a separate codebase, it is not just as easy.

4. Abandon inheritance for aggregation. 

->Perform complex refactoring to move the fields and
methods from BpelDefinition to a new ModuleDefinition.

5. Introduce an "AbstractProcessDefinition" class.


->This implies analyzing each occurrence of
ProcessDefinition in the jBPM codebase to determine whether
it means "generic process" or "jpdl
process".

With the PVM in sight, (4) and (5) are not worth the effort.
(1) or (2) seem fair. What do you think?

View the original post : http://www.jboss.com/index.html?
module=bb&op=viewtopic&p=4017320#4017320

Reply to the post : http://www.jboss.com/index.
html?module=bb&op=posting&mode=reply&p=4017320
_______________________________________________
jboss-dev-forums mailing list
jboss-dev-forumslists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-dev-foru
ms

Check out the exception_notifications plugin. That might be
what you
are looking for.

-carl

On 2/15/07, esconsult1 <esconsult1gmail.com> wrote:
>
> Is there a way to monitor the production logfile so
that when an error
> occurs, it can trap and email the error to me?
Alternatively, is it
> possible to write errors out to a separate logfile.
>
> A few months ago I read something where a couple of
guys where doing
> this on their production site. Their goal was to get
errors down to
> practically zero in a short period of time.
>
> I know its possible to hack the logging to get
something like this in
> place, just wanted to know if someone already had a
solution before I
> started re-inventing the wheel.
>
> Regards
> - Ericson Smith
>
>
> >
>


-- 
EPA Rating: 3000 Lines of Code / Gallon (of coffee)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Deploying Rails" group.
To post to this group, send email to
rubyonrails-deploymentgooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-deployment-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-deployment
?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi,

2007/2/16, esconsult1 <esconsult1gmail.com>:
>
> Is there a way to monitor the production logfile so
that when an error
> occurs, it can trap and email the error to me?
Alternatively, is it
> possible to write errors out to a separate logfile.
>
> A few months ago I read something where a couple of
guys where doing
> this on their production site. Their goal was to get
errors down to
> practically zero in a short period of time.
>
> I know its possible to hack the logging to get
something like this in
> place, just wanted to know if someone already had a
solution before I
> started re-inventing the wheel.

You may have a look at Exception Notification plugin :
http://wiki.rubyonrails.org/rails/pages/ExceptionNo
tification

Rails will send you mails when exception occurs.

  -- Jean-François.

-- 
Ruby ( http://www.rubyfrance.org ) on Rails ( http://www.railsfrance.org
 )

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Deploying Rails" group.
To post to this group, send email to
rubyonrails-deploymentgooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-deployment-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-deployment
?hl=en
-~----------~----~----~----~------~----~------~--~---