no, it is still not finished, but improved a lot in 3.3.1
1) is being taken care of in 4.0... logging is changing and will be configurable as well.
The thing is that 'governance' sometimes requires a lot of info... so it is a
tradeoff...
2) as said before... if there is a technical error by which a transaction is rolled back,
nothing has happened in the process. Yes, there is an error, but that should be dealt with
on a different level... not the process logging....
In one of the production systems I developed (non-jbpm based, not even workflow) we made
the logging async in a transaction to an in-memory jms queue. That would write data to the
db afterwards... An issue of what to do if the system crashes and not all logging has been
written to the db.... again... it is a tradeoff....Writing it to the local filesystem is
*not* high availability... most crashes we had were due to disk crashes... but you can
configure the jms queue to use local file persistence (we tried that and it works, but
switched back to keeping it in-memory).
So logging async (JMS) with local file persistency as storage before the log is actually
written to the database is imo a good solution. Regarding your main problem.... patches
are always welcome....
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207817#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...