I recommend an interceptor. As regards transactional behavior, if you need it completely transactional, send the messages as the setter invocations go by in the tx context (make sure your interceptor is after the tx interceptor so the thread gets the right tx). If you only need 95% (??) reliability you can accumulate the messages in a list in the interceptor, register a synchronization object with the tx, and send them all (non-transactionally) on afterCompletion(true) or not if the tx rolls back.
In the setup methods (probably start, maybe init) you can examine the methods of your ejb and make a set of methods that you want to respond to. Then, when an invocation goes by, you get the method object out, see if it's in your set, and decide whether to audit it. I don't understand how your jrmp invoker idea would work. For one thing, it won't necessarily have the correct tx context, so there may be no way whatsoever to get the messages transactional. If you want fancier behavior you could encourage me to finish the rule engine plugin I wrote which works on more or less this principle and would let you apply fancy rules to deciding whether or not to send the message. david jencks On 2002.07.31 21:00:30 -0400 Gerald Turner wrote: > I'm working on a project with JBoss which has a few odd requirements I > think would be nice to implement with JMS/MDBs and some JBoss hackery: > > Auditing of particular entity bean setters. > > It'd be cool if transacted messages (containing bean name, method name, > old value, new value, and Principal) were produced onto a Topic so that > a MDB could pick them up, check if they're interesting (because system > admins will want to shut off auditing of certain beans or setters), and > optionally do what it takes to "audit" (execute a SQL insert into some > audit table, or perhaps ejbCreate an Audit bean). > > Problem is the beans are CMP, so I can't simply produce messages by > writing some code on the setters because they're abstract, AFAIK it must > be done through some "interceptor". The JBossSX SecurityProxy came to > mind, but I don't think it will participate with the transaction context > (it's just an interface afterall), in other words, if the transactions > where these setters are being invoked get rolled back, the auditing will > still occur. > > So I've been thinking about setting jboss.xml bean-invoker elements for > these entity beans to my own subclass of JRMPInvoker (that's what they > default to FWICT) that overrides 'invoke', calls 'super.invoke()', and > produces messages... I've never touched MBeans before, so I'm quite > uncertain that any of this will work, or perhaps there's a better way - > I thought I'd ask the list before I dive into JBoss internals. > > Any advice would be greatly appreciated! > > > There are a couple more EJB-rule-breaking things I'd like to try such as > the message selector equivalent of Dynamic QL, but that comes much > later. > > -- > Gerald Turner Email: [EMAIL PROTECTED] Phone: (503) 788-1720 > GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5 > > > ------------------------------------------------------- > This sf.net email is sponsored by: Dice - The leading online job board > for high-tech professionals. Search and apply for tech jobs today! > http://seeker.dice.com/seeker.epl?rel_code=31 > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > > ------------------------------------------------------- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
