[quote=asaudate][quote=AUser][quote=asaudate][quote=AUser]Pois é, mas olha só o caso:
Tenho uma tabela User, e uma UserLog, toda vez que ocorre uma determinada ação no sistema, é inserido um registro nessa userLog (efetuou login, alterou permissões, etc). O problema disso é que não considero uma abordagem muito prática, visto que o software não é um repositório de logs e essa parte de auditoria, eu gostaria que ficasse de fora do sistema (literalmente arrancar essa tabela de userLog). A necessidade prática é essa, agora o log4j + aspect4j também não me atende, pois não é legal logar desse jeito quando tenho 5k de usuários, por ex. Como vou salvar os logs? Em txts separados? Não me parece mto convicente…
É numa solução dessas que estou atrás.
[]'s[/quote]
Você pode usar só o AspectJ, então, e salvar o usuário em banco. OU até criar um appender customizado pro Log4J, visto que o pessoal de operações ia te agradecer muito, mas muito MESMO, se você fizesse isso, já que eles iam poder configurar de fora se eles querem persistir as mensagens de log, salvar em arquivo, mandar pra um SAN, etc.
[]'s[/quote]
Opa ASaudate,
Obrigado pela resposta. A questão é que ando receioso a tudo isso. Por exemplo, eu ando avaliando realmente se existe essa questão de persistir o usuário no mesmo banco de dados do sistema. Isso tudo pra mim, é coisa separada que não faz parte do sistema. E essa parte de log também tem me incomodado muito. Vc tem algum paper sobre isso?
obrigado[/quote]
Não, não tenho nenhum paper a respeito… mas acho que você está certo em considerar a questão, já que o usuário pode vir de diversas fontes (AD, BD, SSO… ) e, de fato, não fazer parte do sistema. Mas o ponto a ser considerado é que ele deve ser referenciado de alguma maneira. Assim, o melhor que pode ser feito a esta questão é você possuir, no seu sistema, um campo varchar, sem FK especificada, para referenciar um usuário. Desculpe não poder ajudar mais nesta questão.
Quanto à questão dos logs, li num livro (Release It! - recomendo muitíssimo) que o melhor que se pode fazer é deixar configurável. Nunca se sabe que espécie de questão o pessoal de operações pode ter que enfrentar, então, o melhor a ser feito é deixar certas decisões nas mãos deles. Na verdade, o livro defendia que não só o sistema de logs deveria ser configurável por fora, mas todo o sistema. Isso inclui pools de threads, comunicação remota, classes a serem usadas em determinados trechos, etc. Notei, inclusive, que o livro não menciona nunca, mas está presente sempre, o Spring - já que ele permite que se faça esse tipo de configuração externa.
[]'s [/quote]
Nunca tinha ouvido falar nesse livro, vou dar um olhada. Outra coisa, sobre essa questão de users também, eu já tinha olhado e esbarrei justamente nessa parte de log e em como ia relacionar as FKs, pra isso tinha pensado em usar o openAM. Mas os relacionamentos que me quebraram as pernas. Pra mim é meio absurdo ter essa idéia de armazenar usuários e logs de acordo com as políticas do meu sistema, até pq, olha o tamanho do retrabalho que há… Quantas mil apps já reinevntaram a roda.
Bom, é isso. Vou pesquisando aqui pra ver se acho mais alguma coisa. Se vc souber algo de log nesse nível que possa me ajudar, vou ficar muito grato. 
Obrigado!